Model events according to service internal domain model, or a shared model?

Question

We have a system built on microservices with 50-100 different services. Previously most servcie-to-service communication was done with direct REST API calls, but we are shifting to a event based architecture (for this question I have simplified the setup a bit)

My question is related to how to model the events between two parts of the system.

We have Creation where a user can create content, and Publishing where a user can publish the created content. Each part is handled by separate development teams. Further, each part is split up into several services, for example PublishingScheduling which does scheduling of when a specific Batch of Content should be published and PublishingIntegration which contains logic for sending a batch of content to different 3rd parties.

Now, a service within the Creation needs to know which content is published, and also which Batch it was part of. In simple terms, Content with id X is part of Batch Y.

The domain model within PublishScheduling and PublishingIntegration is of course not as simple as Batch Y contains Content X but contains a whole hierarchy of different objects not really relevant to anyone outside of Publishing. And this hierarchy is necessary to understand to know which pieces of Content is part of which Batches and if its published or not.

What should the events sent out from PublishScheduling and PublishingIntegration look like? There are two main viewpoints:

• The Publishing team argues that because this is microservice architecture, each service should publish events according to their internal domain model. That would mean ~10 different events, for example ContentAssigned(contentId, placeholderId) when Content is assigned to a Placeholder, BatchCreated(batchId) when a Batch is created and so on. If the Creation team does not want to put all the logic to decode this, then Creation can add a "Anti Corruption Layer"-service that does the translation.

• The Creation team argues that since these events are used outside the PublishScheduling and PublishingIntegration domains, they should contain data structured according to a shared domain. In this case that domain would only contain Batch and Content, so events like ContentAddedToBatch(batchId, contentId) would be the result.

Answer 1

In my opinion the best approach here would be for the Publishing team to publish events that follow a shared domain model. This will make it easier for the Creation team to understand and use the events, as well as eliminate the need for a separate "Anti Corruption Layer" service.

While it is important for each service to have its own internal domain model that makes sense within the context of that service, it is also critical to ensure that the events published by a service are structured in a way that other services can easily understand. This will make communication and collaboration between services easier, which is the ultimate goal of using a microservices architecture.