Chapter 5. Domain-driven design

Sometimes, humans require some distance to fully comprehend a thing. An example is an impressionist painting. When you look at one of these paintings up close, all you see are colored dots and small brushstrokes; you don’t see a clear image. When you back away from the painting, it becomes clear, and you can see a child on a swing, a park, or a lake. This situation is similar with a large architecture, a reactive architecture being no exception. In this spirit, we take some steps back in this chapter to look at a reactive application from a distance, starting with the next item in the reactive toolbox, domain-driven design.

In building reactive architectures, you need not venture into unknown territory. Helpful patterns and technologies already exist that allow you to program the reactive way with a lot less effort than you think—if you learn to use and embrace some well-known standard items in your toolbox. As with the construction of a house, if you know how to build a wall, a floor, and a roof, building the entire house isn’t too much of a stretch. With this approach to domain modeling, you can begin building systems that adhere to the Reactive Manifesto, giving you message-driven, elastic, responsive, and resilient capabilities.

5.1. What is domain-driven design?

5.2. An actor-based domain

Summary