Skip to content

Domain-Driven Design

Domain-Driven Design (D-DD) is a term coined by Eric Evans in his book ”Domain-Driven Design – Tackling complexity in the heart of Software”.  The definition of D-DD is an approach of developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.

Why do it?

The premise of D-DD is the following: –

  • Placing the project’s primary focus on the core domain and domain logic.
  • Basing complex designs on a model.
  • Initiating a creative collaboration between technical and domain experts to iteratively cut ever closer to the conceptual heart of the problem.
Domain Design of Household Finances
Domain-Driven Design of Household Finances

Above is a representation of entities, and objects within the context of household finances. This example defines the relationships between these objects and helps understand the problems that require a solution.

How to initiate Domain-Driven Design

To facilitate a deeper understanding of D-DD, there are a number of core definitions to highlight: –

  • Domain: A sphere of knowledge, influence or activity.  The subject areas to which the user applies a program is the domain of the software.
  • Generic Sub-domain: Common components seen in infrastructure such as Netscaler, SQL etc.  These are COTS and you should never build them.
  • Supporting Domain: Systems that organisations have to build however these do not differentiate from competitors.
  • Core Domain: Directly addresses the company strategy.  This differentiates from competitors.  This focuses development effort within this 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.
  • Context: The setting in which a word or statement appears that determines its meaning.

Modelling a domain provides a solution to a problem.  This is a creative and collaborative exercise between developers and domain experts which goes across stories and iterative development.

To enforce a consistent and shared view of the domain (within a bounded context) between developers and domain experts, Models should be unambiguous and a glossary should be in place.  This defines a common language that could allow the use of Domain-Specific Programming Language (DSL) such as Boo.

The Prerequisite for a Success

There are a number of prerequisites for the successful application of D-DD: –

  1. The domain is not trivial.
  2. Project teams have experience and interest in OOD.
  3. You have access to domain experts.
  4. You have an iterative process.

Further Reading

There are two core areas of D-DD.  These are: –

1 thought on “Domain-Driven Design”

  1. Pingback: Simon D

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from James McGuigan

Subscribe now to keep reading and get access to the full archive.

Continue reading