Domain-Driven Design: A Short Introduction to a Complex Software Development Approach

In this blog post, I will try to define Domain-Driven Design (DDD), concentrating on one of its concepts, Ubiquitous Language (UL). This is a just quick overview, not the full explanation. I intend to give you a small glimpse into the terminology and practices that DDD represents. 

For further reading about DDD, you can find references at the end of this writing.

What is Domain-Driven Design (DDD)?

I will not try to give yet another definition of domain-driven design, so I’ll share one from dddcommunity.org:

Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.

At first, it sounds very complicated, but the goal of practicing DDD is to handle complex scenarios with a systematic approach in a way that domain experts (stakeholders, product users, etc.) and the development team (product owner, software architects, developers, etc.) can collaborate effectively with minimum friction.

To achieve this, both strategic and tactical tools and patterns are employed. One of the most important tools is communication. To handle communication between the involved parties, DDD utilizes Ubiquitous Language (UL).

What Is Ubiquitous Language (UL)?

UL is a term used in Eric Evans’ Domain-Driven Design. It is a team pattern used to capture the concepts and terms of a specific core business domain in the software model itself. The main goal of UL is to rigorously define the meanings of words and avoid ambiguity.

For example, the word client can have very different meanings in different contexts. A client could be a human identity with a username and password used to authenticate within a webpage, it could also be a system service which consumes an API. Similarly, the term booking could mean reserving a ticket for an event, but it could also refer to a player being punished by the referee for foul play.

These simple examples illustrate the importance of clearly defining the meanings of each word and term. This is especially important where many departments and business units are working side-by-side and collaborating on large-scale projects.

This brief overview clearly illustrates the importance of domain-driven design and its concepts for managing and maintaining complex software projects.

The question remains, when should DDD be employed? Well, it depends. For small projects, it’s definitely overwhelming, but this doesn’t mean that individual parts of DDD can’t be used. After all, it’s not all or nothing. On the other hand, for large projects, the DDD approach is almost unavoidable.

For success, enforcing all DDD patterns, tools and best practices is imperative, so that project development goes smooth, without any friction. Happy DDDing! 😊

References:

• Implementing Domain-Driven Design, Vaughn Vernon
• Domain-Driven Design: Tackling Complexity in Software, Eric Evans
• https://dddcommunity.org/
• https://www.martinfowler.com/tags/domain%20driven%20design.html