Domain Driven Design

What is DDD?

Domain-driven design consists of a set of patterns for building enterprise applications from the domain model out. Its about mapping business domain concepts into software artifacts. According to wikipedia,

Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model.

The idea first described by Eric Evans in his book. Most of the info in this article have been based on Eric Evans' book "Domain Driven Design", covering the domain modeling and design aspects mainly from a conceptual and design stand-point.

Why?

There’s no doubt that the developers love the challenge of understanding and deploying complex technologies. But understanding the nuances and subtleties of the business domain itself is just as great a challenge. If we devoted our efforts to understanding and addressing those subtleties, we could build better, cleaner, and more maintainable software that did a better job for our stakeholders. And there’s no doubt that our stakeholders would thank us for it.

A domain model offers several benefits some of which are:

• It helps to create a common model, between the business side and IT side in the company, that the team can use to communicate about the business requirements, data entities, and process models.

• The model is modular, extensible and easy to maintain as the design reflects the business model.

• It improves the reusability and testability of the business domain objects.

Concepts

There are some central ideas at the heart of domain-driven design.

• Domain: A sphere of knowledge upon a subject area in which the user applies a program is the domain of the software;

• Model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain;

• Ubiquitous Language: A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

Ubiquitous Language is a common language between the domain experts and developers by using the concepts of the domain model as the primary means of communication. Use the terms in speech, in diagrams, in writing, and when presenting. If an idea cannot be expressed using this set of concepts, then go back and extend the model. Look for and remove ambiguities and inconsistencies.

Meanwhile, model-driven design is about capturing that model in a very straightforward manner in code. Let’s look at each in turn.

Purpose of Ubiquitous Language

Failure of projects are very common in the IT industry. Too often systems take longer than intended to implement, and when finally implemented, they don’t address the real requirements anyway.

Over the years we in IT have tried various approaches to address this failing like waterfall methodologies and agile methodologies.

But at the end of the day what really matters is communication between the domain experts (that is, the business) who need the system and the techies actually implementing it.

If the two side have problem understanding what is required, then the chance of delivering a useful system will be next to nothing.

For bridging this gap DDD can come handy and proved to be helpful. The aim is to have the business and developers using the same terms for the same concepts in order to create a single domain model. This domain model identifies the relevant concepts of the domain, how they relate, and ultimately where the responsibilities are.

How to create Ubiquitous Language

Creating a ubiquitous language calls upon everyone involved in the system’s development to express what they are doing through the vocabulary provided by the model. If this can’t be done, then our model is incomplete. Finding the missing words deepens our understanding of the domain being modeled.

A ubiquitous language demands that the developers work hard to understand the problem domain, but it also demands that the business works hard in being precise in its naming and descriptions of those concepts. After all, ultimately the developers will have to express those concepts in a computer programming language.

In Extreme Programming, there is a similar idea called a system of names. But ubiquitous language is much more evocative. Often the “domain experts” come from different branches of the business. Even if we weren’t building a computer system, there’s a lot of value in helping the domain experts standardize their own terminology.

If the domain experts have a very good idea of what the business process should be, then that’s a good candidate for automation, that is, including it in the scope of the system. But if the domain experts find it hard to agree, then it’s probably best to leave it out. After all, human beings are rather more capable of dealing with fuzzy situations than computers.

So, if the development team continually searches to build their ubiquitous language, then the domain model naturally becomes richer as the nuances of the domain are uncovered. At the same time, the knowledge of the business domain experts also deepens as edge conditions and contradictions that have previously been overlooked are explored.

Model-Driven Design

There must be a straightforward and very literal way to represent the domain model in terms of software. The model should balance these two requirements: form the ubiquitous language of the development team and be representable in code. Changing the code means changing the model; refining the model requires a change to the code.

For our ubiquitous language to have value, the domain model that encodes it must have a straightforward, literal representation to the design of the software, specifically to the implementation. Our software’s design should be driven by this model; we should have a modeldriven design.

By design we mean a way of organizing the domain concepts, which in turn leads to the way in which we organize their representation in code. We can express domain concepts using classes and interfaces, and we can express the relationships between those concepts using associations.

Differences between TDD, BDD, DDD

TDD stands for Test Driven Development. Is a way of software development where the test for a function gets written first, then the function. You know you are done when the function passes the test. The benefit is that it promotes simpler designs, and promotes confidence that the system works as expected

BDD stands for Behavioral Driven Development. While it is a refinement to TDD, it concentrates in understanding the user’s behavior, and yields nicely to a good acceptance of the end system. The benefit is that it offers a more precise and organized conversation between developers and domain experts.

You have to choose the methodology that fits your requirements of the development. but how? Well, we can talk about this in the next post. Stay tuned.

References:

• http://dddcommunity.org/book/evans_2003/
• https://pragprog.com/book/dhnako/domain-driven-design-using-naked-objects
• https://en.wikipedia.org/wiki/Domain-driven_design#cite_note-definition-1