Three pillars of DDD
In this book, Evans introduced three main concepts (sometimes called pillars) of DDD. These are ubiquitous language, strategic design, and tactical design. We have summarized them in this section, but we go into each in more depth later in this book.
Ubiquitous language
Ubiquitous language is the term we use to describe the process of building a common language we can use when talking about our domain. This language should be spoken by everyone in the team—developers and business folk alike. It unites the team by ensuring there is no ambiguity in communication.
As with real languages, the ubiquitous language should evolve as your team’s understanding of the domain increases. It should never be imposed by domain experts, for it is not a business language. We will discuss how to develop a ubiquitous language in Chapter 2.
Strategic design
Strategic design is a phase of the DDD process in which we map out the business domain and define bounded contexts.
The goal of strategic design is to ensure that you architect your system in a way focused on business outcomes. We do this by first mapping out a domain model, which is an abstract representation of the problem space. If you were working on a shipping system, your domain model might look like this:
Figure 1.1 – A domain model diagram representing a shipping domain
Notice how shipping is at the center of the diagram? This is part of the core domain, and all the surrounding points are there to support shipping.
There is more work to be done here to create bounded contexts, but even at this very early stage of the DDD process, you can start to think about how your system might look.
We will talk about bounded contexts in much more detail in Chapter 2.
Tactical design
Tactical design is where we begin to get into the specifics of how our system will look. In the tactical design phase, we begin talking about entities, aggregates, and value objects, which also happens to be the title of Chapter 3 of this book. We will use these patterns to help us define software boundaries.