Chapter 1, Why Domain-Driven Design, in this chapter, we will briefly touch upon the concepts of problem and solution spaces, requirements, complexity, knowledge and ignorance. Although at first, the topics seem not to be directly related to software development, they actually have a significant impact on how and what we deliver.
Chapter 2, Language and Context, in this chapter, we will discuss the importance of language in system design and how precise and unambiguous terminology brings clarify and shared understanding of the domain for business people and developers. We will also look at how different industries use the same words to express different concepts and what consequences this has for domain modeling.
Chapter 3, EventStorming, in this chapter, we will learn what EventStorming is, why every team would benefit from organizing such a workshop with domain experts, to gain domain knowledge and decrease ignorance. We will also go through practical tips on how the EventStorming session can be arranged and facilitated.
Chapter 4, Designing the Model, in this chapter, we will identify what is the domain model and agree that the model is representing some part of the real life, which is targeted to solve some specific problem. We will also discuss the importance of behavior and that it is the essential part of the model, which is often overlooked and even ignored. Along the way, we will introduce the CQRS pattern. It separates commands as something to be done inside the model and represent behavior, from queries that have the only purpose of retrieving state.
Chapter 5, Implementing the Model, in this chapter, we will start to write a lot of code and learn the basics about implementing domain models in code. We will look at entities and value objects, what are they needed for and how different they are. Explaining the power of value objects took a great deal of this chapters and this topic is vital since value objects are often overlooked.
Chapter 6, Acting With Commands (WIP), as we learned, everything the system does can be represented as a sequence of events. However, what is the trigger for these events to appear? Obviously, as events are reactions, something needs to be an action. These actions are called commands. In this chapter, we will learn what commands are, how commands are being handled and how events are produced as the result of executing commands. We will create commands and handlers in code.
Chapter 7, Consistency Boundary, in monolithic systems, everything seems to be fully consistent. To achieve consistency, a lot of logic is outsourced to the database engine and becomes implicit, hard to figure out at a glance, and hard to test. Database transactions are frequently used to ensure that multiple state mutations are executed at once. If data becomes inconsistent – that usually means failure and requires extensive discovery to fix the issue. In this chapter, we will compose some aggregates and see how operations on them can be performed via the aggregate root. We also evaluate possible persistence methods for aggregate and get into the concept of the repository – a place, where the aggregate state is stored.
Chapter 8, Bounded Context, traditional systems are often made as one single application, may be split into layers. We already discussed issues that this approach brings with it. How does Domain-Driven Design address this problem? In DDD we realize that the Ubiquitous Language is context specific. Same words have a different meaning in different context. This means that trying to combine all information about something in a single entity rarely works. Each context creates its own nuances in the terminology and therefore has its own demand for data and behavior.
Chapter 9, Event Sourcing, we already understand what domain events are, why are they important and how to find and code them. Now, we will look into another use of events. This time, we will learn how events can be used to persist the state of an object, instead of using traditional persistence mechanisms like SQL or document database. This is not an easy thing to grasp but the reward is satisfying. Using events to represent the system behavior and derive its state for any given moment of time has many advantages. Of course, there are drawbacks that are important to an understanding before deciding to use this technique.
Chapter 10, Projections and Queries, in this chapter we will learn how about CQRS and how to create projections, which keep a copy of an aggregate state in a more traditional way – as a table row or a document. In order to do this, we need to learn the concept of subscriptions and figure out how to use them in EventStore
Chapter 11, Integration with Events, in this chapter we will learn the concept of integration events and important messaging patterns like publish-subscribe. Also, we will implement simple integration using a message bus. After that, we need to look into the matter of complex processing flows, which may span across different contexts. Such processes usually intersect with the concept of distributed transactions. Following the classic “Your Coffee Shop Doesn’t Use Two-Phase” paper by Gregor Hohpe, we will go through patterns of implementing asynchronous processes, like routing slip and process manager.
Chapter 12, Setting Things Up, in this part is all about the UI. In all previous parts, we were moving from modeling our problem with sticky notes to the actual event-driven code. Now it is time to show something on the screen in addition to black console windows.
Chapter 13, Task-Based UI, using commands and events can have an effect on how the user interface is built. In particular, since commands represent very explicit actions and events capture the granular intent of the user, the user interface should be able to produce such commands.
Chapter 14, One-Way Flow, front-end frameworks like AngularJS or Knockout by default support two-way binding between views (rendered HTML elements) and models (JavaScript classes). This approach is convenient but also has many drawbacks. We will look into issues with two-way binding and explore possibilities to avoid these issues with one-way binding.
Chapter 15, Refactoring, Domain-Driven Design promotes the concept of refactoring towards deeper insight. We do not only make changes to our software when this is required because the business needs some new functionality or wants to change the outcomes of the existing system. We also rewrite our code when we discover new, missing or wrongly understood domain concepts. This process is continuous and it is only possible when developers are engaged in ongoing dialogue with the business. When getting new insights into the domain, developers need to represent this knowledge in code. We will also learn how new requirements can be implemented by building new read models and how they can be deployed in production without having an effect on other parts of the system.
Chapter 16, Versioning of Events, unlike state persistence, events cannot be just edited. When for traditional storage we would change the database schema or create a new document instead of the old one, such an approach would not work with event streams. Although this is difficult, there are a couple of things to bear in mind. First, changes that require migrations of events are not done very often. Second, there are patterns and practices on how such migrations can be done and we will briefly go through them and implement a couple.
Chapter 17, New Horizons, during the journey of this book, we discovered many concepts and techniques, which allow creating comprehensive flexible systems with a long lifecycle and high degree of isolation. What to do next? There are many things to explore, from things how DDD effect interaction between people and teams, how organization structure affects software systems, to more technical things like how to execute complex event processing, how to use different type of systems that can store events and how to build highly distributed but also very reliable and resilient systems.