Domain-Driven Design (DDD) is a development approach that prioritizes the business domain over the technical implementation. It aims to manage complexity by making sure that the code accurately reflects the business needs. DDD is divided into two levels of design: strategic and tactical.
The big picture (strategic) level focuses on how different parts of large systems relate to one another. DDD introduces the term “Ubiquitous Language,” which means that developers and domain experts use the same terminology for both conversations and coding. This means that there is no need to translate the business requirements to code and vice versa. The next big concept, at the strategic level, is the bounded context. The bounded context is a boundary around a specific part of the system (e.g, “Registration” vs “Checkout”), inside a boundary, terms have a specific unified meaning. DD also uses diagrams, such as the Context Map, which illustrates how Bounded Contexts interact with each other.
The tactical level represents the building blocks, inside a given bounded context. We have entities that are objects with unique IDs that stay the same evening if their data changes. A user can edit their order, but the order ID should remain the same. Next, we have value objects, which are defined only by their attributes; there are no IDs here, and value objects are immutable. Another important terms are the aggregates, which represent a cluster of related entities and value objects that get treated as a single unit. We also have repositories, which are tools used to retrieve and save aggregate data, for example, abstracting away the database interaction. Lastly, we have domain events, which can be seen as notifications that something happened, such as a customer placing an order.
The aid of DDD is to prevent the “Big Ball of Mud” architecture, which is hard to manage, and it forces the developers to model the software based on how the business actually functions.
