BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Designing Reactive Systems Using DDD, Event Storming and Actors

Designing Reactive Systems Using DDD, Event Storming and Actors

Bookmarks

Domain-driven design (DDD) is often used for finding boundaries (bounded contexts) around microservices. Aggregates, also from DDD, are important for defining the scope of persistence and consistency. But everything in domain-driven design (DDD) is not good for microservice, Lutz Huehnken claimed in a presentation at microxchg 2018 in Berlin where he discussed how DDD, Event Storming and the Akka-based Lagom framework can be used to build reactive systems with a 1-1 mapping between model and implementation.

Traditionally in DDD there has been a focus on the static structure of system; you talk with domain experts listening for the nouns. For Huehnken, a freelance consultant, this focus on static properties often leads to poor boundaries. Instead he claims that we should focus on the dynamics and the events. In the early stages of design, it’s not the things that matter, it’s the things that happen.

Event storming

Event storming is primarily a workshop format from the DDD community that allows for the rapids exploration of complex business domains. A large wall is used as the modelling surface and self adhesive paper notes are used to represent the model. You assemble business people and developers and start with capturing events in order to identify the things that happen in the domain. When you find events you also try to order them along a timeline. After that you add the command that triggers each event. Instead of creating aggregates at this point based on entities that seem to belong together, Huehnken wants the aggregates to emerge from the flow of commands and events. This gives a different view on aggregates — they logically group commands and events together — and he firmly believe this will give you better boundaries and help in separating aggregates into different services.

In Huehnken’s experience, event storming is a powerful tool especially in regards to the big picture, but can also be used at different levels. He has found that you also can use it at a more technical level for modelling your services down to the aggregates. One huge advantage this gives is the alignment of the model and the implementation, which is of great value in DDD.

Reactive systems

Reactive systems are about building responsive, resilient, elastic and message driven systems. The means to achieve this is asynchronous messaging. For Huehnken, microservices are about isolation, moving fast and being able to deploy a new version of a service without affecting the rest of the system, so for him the two concepts complement each other very well — we need reactive microservices.

The textbook technology to implement reactive systems are actors, but Huehnken noted that this model is not as widespread as he would like, and he believes the reason for this is the mental leap needed when leaving the monolith. In the monolith you have access to everything and can cross over the logical boundaries that exists. In a truly distributed system, with network boundaries, you don’t have access to the system as a whole. Business processes that involve several aggregates may requiring patterns like sagas etc. You also move away from the global state of "now" (in regards to time); in a distributed system you have a local now and then you have the past represented by events.

Huehnken claims that there are interesting implementation techniques in relation to the actor model. There are several frameworks available, including Erlang and Akka. Lagom is a newer, more opiniated microservices framework that is based on Akka, CQRS and event sourcing. Although people struggle with building completely asynchronous decoupled systems due to the mental challenge, he thinks there is an opportunity here if we can align our modelling technique with our implementation technique.

In DDD it’s important that the code expresses the concepts of the model. Huehnken believes we have lost track of this. We have developed our implementation techniques, and separately we have developed new modelling techniques. We now have to bring them together so that the concepts from the modelling are directly reflected in the code — then we will have a real breakthrough in our way of building distributed systems.

The presentations at the conference were recorded, some are already published with more to come.

Rate this Article

Adoption
Style

BT