We don't know where to implement a certain enum and how to propagate it throught our services, that need it. We need this enum "SampleType" in two of our microservices (for now). Our services communicate mostly via REST endpoints with autogenerated client files via Swagger. We have one repository service for our "inventory data", that is shared across most of our services, that reads from and writes to our main databases. Some of our other services have their own small dbs for certain things that are specific to these services.
So, this SampleType enum is specific to one service A, but is needed in at least one to two other services B and C as well. A is writing objects with this enum into its own db. It communicates with at least B and C via REST and sends and receives these objects that contain the enum.
For safety reasons, A would need to define at least its own SampleType because it writes it to a db. But it would be nice if we could define it in our main repository service and propagate it without future issues to all services that need it via REST endpoints (swagger includes enum definitions). There is logic behind this enum, so a centralised change would need to flag issues at compile time.
We have also tried using a central library which is distributed to the services as a Nuget package, however this results in two separate definitions (nuget + swagger).
What are generally preferrable ways of defining and propagating the enum definition? Is there a simpler way or is it indeed mandatory in such cases that a service defines its own enum and maps if necessary?
SampleTypeis specific to service A it should probably be part of Service As public API. But you write nothing about your version handling strategy. If Service A is modified, Service B should be able to continue using the older API for some time, and an enum change would be considered an API change.