Generic model defined and used by different Microservices

Question

We Have a scenario where we are monitoring machines so called endpoints.We receive the data for events happening in a machine in kafka through some mechanism. Two different microservices are listening to the topic to process the data. Both services have different purpose

1. Alerting : For generating alerts based on the data in the topic.
2. Asset: Showing Machine Event Data coming in the topic to our clients.

The problem that i see is that we have defined a common model for below cases as a library:

• To serialize the data at machines to be sent to kafka for the services to be consumed.
• To deserialize the data consumed by the two services mentioned above (Alerting and Asset)

I feel this is a wrong way to define models in Microservice environment , because that introduces coupling among sub-domains which are not directly related to each other and are representing different bounded context. In the above case

• Alerting(Bounded context): Generate alerts based on the data.(Business capability or sub-domain)
• Asset(Bounded context): Showing Machine Event Data to clients (another sub-domain)

Also the common model as a library breaks the below requirements:

• Basic requirement of Bounded context that they must be autonomous , change in the common model will affect either of the services.
• Microservices should be independently deployable, change in the model will mandate both the services deployed separately even if the change wasn't of any use for any one of the services.

The Solution i feel apt for this scenario is to have separate models instead of a common model for both the services as a representation of the incoming data in the topic or use the data in one service by requesting to another service and create an association between the two services.

Need to understand which is the correct approach for the micro services.

Answer 1

Perhaps there is a bit that may be unique to your situation that I don't see at this point which may mean that you need to not have a common library but from what I can tell there is nothing wrong with your existing implementation that has a common library.

In some instances you may even have a Shared Kernel which is exactly that.

This is not coupling different bounded contexts together but you are relying on some bit of functionality that, when it changes, may result in your endpoint requiring some rework and redeployment. The fact that more than one bounded context relies on that functionality is inconsequential.

In the same way I may be using some Nuget package that is upgraded with a breaking major version resulting in an upgrade to that version requiring a redeployment of my endpoint. Although in this case it would probably be the actual endpoint and not be directly related to the bounded context domain model.