Domain Driven Design, an elevator pitch

A very short intro to software design using DDD

Domain Driven Design — elevator pitch
Photo by Jason Dent on Unsplash

Domain Driven Design (DDD) has been practiced since Eric Evans first coined the term in his book in 2004, however, there are still many professionals involved in the software development process that have not yet heard the term. I will try to explain briefly what DDD is, by using an elevator pitch and a picture.

The pitch:

DDD is an approach to software development, a set of techniques and practices to aid the process of defining and building software solutions. It brings together business people (domain experts) and developers. Working as a one team, they define the model of the domain, and express it as a set of diagrams. The model is developed in such a way that developers can easily implement it, whilst the experts’ knowledge of the business gets translated in to the working software.

This is a vastly oversimplified explanation of DDD, but this is all you can do in an elevator. If you get someone’s attention, show them this picture and give more details:

The experts and developers meet frequently and discuss the problem at hand. They explore the domain in what are known as knowledge crunching sessions. They break up the domain into several sub-domains, each with its own model at its center. These sub-domains have boundaries and each one represents a different aspect of the business, a different context.

These sub-domains are also called Bounded Contexts because each model, consisting of entities, has its own language associated with it. Entities are bounded inside a context and the same entity will have a different meaning within the boundaries of a different context.

The language used to describe the model and its entities is called a ubiquitous language. Ubiquitous means everywhere, and it's called that, because it is used by all involved in the process of knowledge crunching: developers, business people, testers, workers in the field, i.e. the language is used everywhere. However, each bounded context has its own, different ubiquitous language, similar to the fact that within the boundary of each country, we speak a unique language. Each model in each bounded context is explained with its own language, and each language has meaning only within the boundaries of its own bounded context.

Let’s look at an E-Commerce Domain. A customer entity will have a different meaning within different bounded contexts.

There are many techniques that help to distill the knowledge of the domain experts and translate it in to the model, but they are beyond the scope of this article. Luckily, there are many resources out there and a helpful community of DDD practitioners. And remember, if you are developing software to solve a complex business problem, DDD is most likely right for you. If you don’t use the DDD, the developers misunderstanding of the domain will probably get distilled in to the code. If you do use DDD, the domain expert knowledge of the domain will translate in to clean and maintainable code that meets the business needs.




Aiding and abetting Domain-Driven Design

Recommended from Medium

Monitoring Service Endpoints with Venus

Boost Smooth Scrolling with iOS 10 Pre-Fetching API

Building a Reddit Bot with Stackery

A Tale of Displaying Random ACFs in WordPress

Governance and The Lydian’s Pool

Launching first app by an external author on NativeBase Market 🎉

Dicether — New game “Plinko”


Clean Domain-Driven Design

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Darko Kantic

Darko Kantic

Software Development Realist

More from Medium

Sales Force Automation Software: Expectations vs Reality

A tale on Software design

Branching Strategies — what to follow?

Backend For Frontend (BFF)