What is Domain-Driven Design (DDD), really?
The concept of Domain-Driven Design, or DDD for short, underscores the importance of matching the language of software code with the business domain. Eric Evans popularised DDD in his now-famous book, “Domain-Driven Design: Tackling Complexity in the Heart of Software.”
While the book is notorious for being hard to read, DDD has quickly gained momentum as one of the forefront approaches to software development. Since its publication in 2003, new communities of DDD practitioners have developed further Evans’ ideas, resulting in many new books and training courses on the approach.
DDD, at its core, isn’t a revolutionary concept. Martin Fowler remarks that the idea of basing software systems on a model of a business domain has been around for decades. Evans’ fundamental contribution with his book was creating an approach-specific vocabulary and identifying critical elements of the DDD concept.
As the name of Evans’ book suggests, the central tenet of DDD is tackling complexity. Since modern business environments can be highly complex, any wrong assessment can lead to disaster. Thus, DDD revolves around solving complex business domains through the use of rigorous and unambiguous software code.
Principles and Terminology of Domain-Driven Design
DDD, according to Evans, is based on three principles — that the primary focus of a project is the main domain and its domain logic (also known as the business logic); that complex designs are founded upon models of the domain; and that the collaboration between technical and domain experts is essential to creating the model that can solve domain problems.
Evans’ classification of domain objects into Entities, Values, and Services is also highly influential. These domain objects are hard to explain – to use a couple of examples, Entities are things such as Customers or Rental Agreements, Values are Date or Money, while Services are usually Repository or Database Connection. A group of these objects bound together is defined as an Aggregate. There are other terms such as Domain Event, which identifies an event that domain experts care about, and Bounded Contexts, networks of large, organized domains.
The Value of Ubiquitous Language
This is all well and good, but why is DDD such a successful approach? The answer is in the clarity of communication that DDD creates between the developers and the rest of the team. In short, by placing the domain at the heart of development, we can simplify and clarify the complexity of the domain logic.
The terminology used during daily meetings is very different from the one used in software coding. Since both tech pros and domain experts use their own jargon, a disrupted language could create miscommunication and ambiguity. Software code doesn’t like ambiguity. DDD allows for a rigorous and common language structured around the domain model, clarifying and simplifying communication complexity in the present and future.
For example, let’s say a company hires a new developer tasked with adding a new field to the customers. The developer should find the piece of code related to the ‘Customers,’ but this could be difficult if the current developers represented customers with a different term such as ‘Clients’! Thanks to Ubiquitous Language, such problems are easy to solve as a clear and univocal language is passed down from the business domain to the software code.
Onbrane: In DDD We Trust!
Domain-driven design is a big deal at Onbrane. The Onbrane team developers, in particular, praise DDD for raising the quality of their platform. “By understanding business issues, we can confidently develop features that really matter to customers. We can make their daily working life easier”.
In addition, DDD’s focus on an unambiguous language paves the way for more direct and fruitful collaboration between the domain experts’ and the developers’ teams. More specifically, the Onbrane developers underline bounded contexts as playing a pivotal role. Through this concept, they can easily direct workflow between teams and use the right technology for each part. Moreover, it was easy to scale up if need be.
The Onbrane developers are creating a state-of-the-art platform that must answer a very complex business logic. Therefore, working on a codebase that avoids technical debts and allows for easily adding or changing features is essential. Thanks to DDD and its concepts, the Onbrane domain experts and developers learn from each other continuously. “At the end of the day, everyone is happy.”
