As a persistence implementation provider (a provider), I want a mechanism so that I can add a new persistence implementation to the EdgeX platform.
As a provider, I want a mechanism for sustaining a persistence implementation so that I do not rely on EdgeX platform releases.
As a provider, I want a mechanism for configuring my implementation without knowing the rest of the EdgeX platform configuration.
As a provider, I want the EdgeX platform build scripts to consolidate my build-time and run-time requirements so that I can maintain my implementation independently of the EdgeX platform.
As a provider, I want an API contact so that I know what to implement.
As a provider, I want an API contract so that I can unit test.
As a provider, I want EdgeX platform testing to be able to certify implementation so that EdgeX platform users will the confidence to use my implementation.
As an EdgeX platform maintainer (a maintainer), I want a default persistence implementation so that I can maintain CI/CT.
As a maintainer, I want providers to create reasonable defaults so that I can add them into CI/CT.
As an EdgeX platform user (a user), I want to select one or more persistence implementations for use by the various Core Data services.
As a user, I want the option to run the platform along with the selected persistence implementation(s) directly on the OS.
As a user, I want the option to run the platform along with the selected persistence implementation(s) in a containerized deployment.

Design

The design has two major roles: the provider and the platform.

Provider Responsibility

The provider makes their plugin,

...

The basis of the requirements came out of looking at how others have solved this challenge.

...