Leaving DDD’s foggy forest

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.

what happens when…

The shape of your Business Purposes and processes and the shape of your software are well matched?

The Essence 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.

The Application of DDD

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.

The Benefits of DDD

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.

  1. DDD requires domain experts to be involved with the software team so that any question about the complexity of the domain can be answered quickly and directly modeled into the system under development. Developers know they are much more likely to provide a solution that is not only acceptable but sometimes even given high praise for making software that is nearly bug free, does the job, does it well and does not need to be replaced due to poor design. More than that, the software is aligned to the domain making it more profitable economically and more pliable for new feature enhancements.
  2. DDD software designs and implementations follow a set of principles and if all the developers on the team have a base understanding of how DDD solutions are formed, they will be able to reason about DDD based code more quickly improving speed to market.
  3. Some believe communication flaws between the business and IT produces billions of dollars of waste in poorly crafted and often failed projects. DDD encourages the establishment of a Ubiquitous Language for the contexts that are in design to intentionally tackle this issue head on. This reduces the need to translate terms between domain experts, the business, current and future developers and even customers. Being on the same page with regards to the language reduces a considerable amount of translation waste that happens in meetings and other communication, but it also reduces software errors.

Other benefits such as reduced coupling, compatibility with many architectures and more make Domain-Driven Design a paradigm suited to many challenging software projects.