DDD, CQRS/ES & MicroServices Should Decisions be taken on Microservice's views or aggregates?

Question

So I'll explain the problem through the use of an example as it makes everything more concrete and hopefully will reduce ambiguity.

The Architecture is pretty simple

1 MicroService <=> 1 Aggregate <=> Transactional Boundry

Each microservice will be using CQRS/ES design pattern which implies

• Each microservice will have its own Aggregate mapping the domain of a real-world problem
• The state of the aggregate will be rebuilt from an event store
• Each event will signify a state change within the aggregate and will be transmitted to any service interested in the change via a message broker
• Each microservice will be transactional within its own domain
• Each microservice will be eventually consistent with other domains
• Each microservice will build there own view models, from events being emitted by other microservices

So the example lets say we have a banking system

• current-account microservice is responsible for mapping the Customer Current Account ... Withdrawal, Deposits
• rewards microservice will be responsible for inventory and stock take of any rewards being served by the bank
• air-miles microservice will be responsible for monitoring all the transaction coming from the current-account and in doing so award the Customer with rewards, from our reward micro-service

So the problem is this Should the air-miles microservice take decisions based on its own view model which is being updated from events coming from the current-account, and similarly, on picking which reward it should give out to the Customer?

Drawbacks of taking decisions on local view models;

• Replicating domain logic on how to maintain these views
• Bugs within the view might propagate the wrong rewards to be given out
• State changes (aka events emitted) on corrupted view models could have consequences in other services which are taking their own decisions on these events

Advantages of taking a decision on local view models;

• The system doesn't need to constantly query the microservice owning the domain

• The system should be faster and less resource intense

  Or should it use the events coming from the service to trigger queries to the Aggregate owning the Domain, in doing so we accept the fact that view models might get corrupt but the final decision should always be consulted with the aggregate owning the domain?

Please, not that the above problem is simply my understanding of the architecture, and the aim of this post is to get different views on how one might use this architecture effectively in a microservice environment to keep each service decoupled yet avoid cascading corruption scenario without to much chatter between the service.

Answer 1

So the problem is this Should the air-miles microservice take decisions based on its own view model which is being updated from events coming from the current-account, and similarly, on picking which reward it should give out to the Customer?

Yes. In fact, you should revise your architecture and even create more microservices. What I mean is that, being a event-driven architecture (also an Event-sourced one), your microservices have two responsibilities: they need to keep two different models: the write model and the read model.

So, for each Aggregate should be a microservice that keeps only the write model, that is, it only processes Commands, without building also a read model.

Then, for each read/query use case you should have a microservice that build the perfect read model. This is required if you need to keep the Aggregate microservice clean (as you should) because in general, the read models needs data from multiple Aggregate types/bounded contexts. Read models may cross bounded context boundaries, Aggregates may not. So you see, you don't really have a choice if you need to fully respect DDD.

Some says that domain events should be hidden, only local to the owning microservice. I disagree. In an event-driven architecture the domain events are first class citizens, they are allowed to reach other microservices. This gives the other microservices the chance to build their own interpretation of the system state. Otherwise, the emitting microservice would have the impossible additional responsibility/task of building a state that must match every possible need that all the microservices would ever want(!); i.e. maybe a microservices would want to lookup a deleted remote entity's title, how could it do that if the emitting microservice keeps only the list of non-deleted-yet entities? You may say: but then it will keep all the entities, deleted or not. But maybe someone needs the date that an entity was deleted; you may say: but then I keep also the deletedDate. You see what you do? You break the Open/closed principle. Every time you create a microservice you need to modify the emitting microservice.

There is also the resilience of the microservices. In the Art of scalability, the authors speak about swimming lanes. They are a strategy to separate the components of a system into lanes of failures. A failure in a lane does not propagate to other lanes. Our microservices are lanes. Components in a lane are not allowed to access any component from other lane. One down microservice should not bring the others down. It's not a matter of speed/optimisation, it's a matter of resilience. The domain events are the perfect modality of keeping two remote systems synchronized. They also emphasize the fact that the data is eventually consistent; the events travel at a limited speed (from nanoseconds to even days). When a system is designed with that in mind then no other microservice can bring it down.

Yes, there will be some code duplication. And yes, although I said that you don't have a choice, you have. In order to reduce the code duplication at the cost of a lower resilience, you can have some Canonical read models that build a normal flat state and other microservices could query that. This is dangerous in most cases as it breaks the swimming lanes concept. Should the Canonical microservices go down, go down all dependent microservices. Canonical microservices works best for CRUD-like bounded context.

There are however valid cases when you may have some internal events that you don't want to expose. In other words, you are not required to publish all domain events.

Answer 2

So the problem is this Should the air-miles micro service take decisions based on its own view model which is being updated from events coming from the current-account, and similarly, on picking which reward it should give out to the Customer?

Each consumer uses a local replica of a representation computed by the producer.

So if air-miles needs information from current-account it should be looking at a local replica of a view calculated by the current-account service.

The key idea is this: micro services are supposed to be isolated from one another; you should be able to redesign and deploy one without impacting the others.

So try this thought experiment - suppose we had these three micro services, but all saving snapshots of current state, rather than events. Everything works, then imagine that the current-account maintainer discovers that an event sourced implementation would better serve the business.

Should the change to the current-account require a matching change in the air-miles service? If so, can we really claim that these services are isolated from one another?

Advantages of taking a decision on local view models

I don't particularly like these "advantages"; first, they are dominated by the performance axis (please recall that the second rule of performance optimization is "not yet"). And second, that they assume that the service boundaries are correctly drawn; maybe the performance issue is evidence that the separation of responsibilities needs review.