I often get this comment when I begin working on a project with a new client.  “I want the system to have a Domain Driven Design architecture…”    Though it’s clear the idea they were trying to get across, the idea of a DDD architecture doesn’t make sense.

The main idea behind DDD is in the name itself: Domain Driven Design.  In applying DDD concepts, we are designing what our domain model will look like and how it will behave.  We imagine the interactions among the pieces, what responsibilities the entities will have and what should be delegated to outside services, which entities belong to which aggregates, etc.  We are deciding how best to implement our domain rules in code so our system is flexible and easily enhanced.

Architecture is deciding the proper infrastructure to properly manage all these pieces. It indicates the transport mechanism to use when sending messages, where data is persisted, and how the system should react to a failure.

DDD can be implemented using different types of architectures, such as a layers (2-tier, 3-tier, etc.), a functional architecture, CQRS, or even the Actor Model or Hexagonal Architectures.  Each of these architectures has their sweet spot depending on the size and purpose of the system, the size and experience of the team, and deadlines or other time pressures.  The most popular by far is a layered design, and when I hear people conflate DDD and architecture I assume this is the architecture they are talking about.

In the real world, this difference becomes significant when discussing deliverables.  The output of a DDD design session is not an architectural diagram.