The internet is bursting with explanations attempting to help readers know what Domain-Driven Design (DDD) is, how to make it actionable in their environments, when not to apply it, and more. Some of these resources are very well done and are a fraction of the best is on our Learning page! To help reduce any confusion quickly, you will find a synopsis, a framework of understanding, to better comprehend the core of this journey. Let’s aim our journey toward success with the essence, application, and benefits of DDD.
Domain-Driven Design, while it has many facets, it has one primary objective – Domain Alignment. If you take any quality DDD training course, it will often consist of lessons on the strategy and tactics of DDD. Both of those thrusts are an attempt at both the decision making and code writing levels to bring software into a high degree of alignment with the business, organization, or agency that the software supports. “Why is this the main concern of DDD?” you might ask. When the software models in code take the shape of the domains, business areas, they serve, as the shape of those domains expand and shift, developers can more easily expand and shift the code in lock step with the business. Software that is not domain-aligned requires designers and developers to first solve these misalignments, then update the software for the new and improved feature, or worse, force new behavior into the software that is not aligned making it less easy to maintain over the life of that software. Misalignment often costs way more than the design effort to avoid that condition. Alignment can be achieved both in the language used to describe solutions, the behaviors that make the domain hum and the data that emanates from those behaviors.
Bottom line, domain alignment is the DDD practitioners goal. Knowledge gathering, requirements development, process modeling and software modeling activities are all designed to make software easier to code, reduce its need for maintenance, make it more useful, far less confusing to modify, and far less error prone by ensuring the model is in alignment with the domain – always.
Domain-Driven Design (DDD) is a set of principles that can apply no matter how many lines of code are intended to be written. The critical question to ask is how complex are the ideas that should live in the brains of the system? How many different areas of concerns should work autonomously? When considering these, DDD gives us both a set of principles in strategizing what to build vs. buy and on the tactical side, DDD give us a set of principles to contain the logic in the brains of the software keeping that logic healthy and not letting those behaviors leak out into the rest of the system. These containers full of complex well designed ideas from the domain should be far more maintainable to anyone who understands these DDD ideas of Bounded Contexts and Aggregates as well as the components that make up Aggregates such as Domain Events, Entities, Services, and Value Objects.
DDD applies strategically if an organization is interested in optimizing autonomous custom development resources. DDD applies tactically to the domain where complex custom software needs to make the solution much more simple no matter the size of the project.
Though some benefits have already been mentioned, let’s take a look at what many consider to be the most important new realities experienced when DDD is applied.
Other benefits such as reduced coupling, compatibility with many architectures and more make Domain-Driven Design a paradigm suited to many challenging software projects.