Domain Driven Design

Tackling Complexity in the Heart of Software
Contributed by

Justin Holmes

Ryan DeBeasi

Published November 06, 2018

What is it?

A set of guiding principles that together form a mindset about building software, often abbreviated as DDD. The concept was introduced by Eric Evans, and the original textbook was published in 2003. The Domain Driven Design perspective is not reductionist, but rather embraces the notion that software development is part of a much larger and complex socio-technical system. As a result, many practices for managing the complexities of software development, like Event Storming, Behavior Driven Development, and Domain Story Telling, have their roots in the DDD community. The stated principles of Domain Driven Design are principles are:

  • Focus effort around the core complexity and opportunity in a domain.
  • Explore models in a collaboration of domain experts and software experts.
  • Write software that expresses those models explicitly.
  • Speak a ubiquitous language within a bounded context.

The words in bolded, italic text above is part of the DDD terminology, which while central to understanding the mindset, is often an times is an Achilles heel.

Why use it?

Domain Driven Design:

  • Helps us understand the way Conway's Law materializes in the software development process.
  • Provides strategies for harnessing Conway's Law to achieve better outcomes.
  • Introduces proven and repeatable patterns for modelling complex business logic in software.

The corollary to the above is the Domain Driven Design is overkill when working on simple domains or simple pieces of software. Only use it if you have complexity to manage.

Further Information


Except where noted, content on this site is licensed under a Creative Commons Attribution 4.0 International license. This site is graciously hosted by Netlify