Backend / Domain-Driven Design / Ddd Vs Clean Architecture

Ddd Vs Clean Architecture

2 min read

Senior3 min read

Rapid overview

DDD vs Clean Architecture
TL;DR
Why it matters
How it works
Side-by-side
Detailed Explanation
A typical DDD-style Clean Architecture layout
Common confusions
When to pick what
Common pitfalls
Interview prompts

DDD vs Clean Architecture

TL;DR

Clean Architecture = a layering rule: dependencies point inward toward the domain.
DDD = how to design what's inside the domain (entities, value objects, aggregates, bounded contexts).
They are complementary, not alternatives.

Why it matters

Constantly confused in interviews. Knowing the distinction lets you discuss either independently and combine them deliberately.

How it works

Side-by-side

Concerned with	Where code lives, who depends on whom	Modelling the business
Output	Layered folder structure	Ubiquitous language, bounded contexts, aggregates
Strategic?	No — purely structural	Yes (contexts, context maps)
Tactical?	Yes (entities, use cases, gateways)	Yes (entities, value objects, aggregates, repos)
Cares about identity vs value?	No	Yes — entity vs value object is core
Says anything about transactions?	No	Yes — one transaction per aggregate

You can do Clean Architecture without DDD (CRUD with a thin domain layer). You can do DDD without Clean Architecture (the patterns live happily in other architectures). They pair well because Clean Architecture protects the domain model that DDD builds.

Detailed Explanation

A typical DDD-style Clean Architecture layout

src/Sales/                       ← one bounded context
  Domain/                        ← DDD lives here
    Customer.cs                  (entity)
    Money.cs                     (value object)
    Order.cs                     (aggregate root)
    IOrderRepository.cs          (interface — points OUTWARD from domain)
    Events/OrderPlaced.cs

  Application/                   ← use cases, orchestration
    PlaceOrder/
      PlaceOrderCommand.cs
      PlaceOrderHandler.cs       (uses domain, calls repos, publishes events)

  Infrastructure/                ← outermost layer
    Persistence/
      EfOrderRepository.cs       (implements IOrderRepository)
    Integrations/
      StripeAdapter.cs           (ACL to external Billing context)

  Api/                           ← Presentation
    OrdersController.cs

Dependencies point inward: Api → Application → Domain. Infrastructure implements Domain interfaces (dependency inversion).

Common confusions

Use cases ≠ domain services. Use cases (application layer) orchestrate; domain services hold business rules.
Hexagonal / Ports & Adapters is the same shape as Clean Architecture — different vocabulary, same dependency rule.
CQRS is orthogonal to both. You layer it on top when reads and writes need different shapes.

When to pick what

Situation	What you need
Junior team, CRUD admin tool	Clean Architecture — no DDD overhead
Complex business rules, multiple stakeholders	DDD + Clean Architecture
Microservices needing clear ownership	DDD strategic patterns (bounded contexts)
Single complex form with validation	Tactical DDD (value objects), no need for context maps

Common pitfalls

Calling Clean Architecture "DDD". They're different concepts.
Putting the repository interface in Infrastructure. It belongs in Domain — that's the whole point of dependency inversion.
Letting EF entities leak into Application as the domain model. That's an anaemic model wearing a Clean-Architecture costume.

Interview prompts

"How are DDD and Clean Architecture related?"
"Can you do one without the other?"
"Where does a value object live in a Clean Architecture project?"
"Use case vs domain service?"

Domain-Driven Design Study Portal