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

• This article is largely a synopsis of Eric Evans' keynote at Explore DDD 2017, which is an excellent talk