Practice : Domain-Driven Design (DDD)

Purpose and Strategic Importance

Domain-Driven Design (DDD) is a collaborative approach to software design that focuses on building deep understanding of the business domain. By aligning technical models with business concepts, DDD enables teams to design systems that reflect real-world complexity and deliver meaningful value.

DDD improves communication between engineers and domain experts, supports strategic decoupling of services, and leads to software that’s easier to reason about, maintain, and evolve over time.

Description of the Practice

  • The domain is the core problem space the software aims to solve; DDD puts this at the centre of design.
  • Key techniques include ubiquitous language, bounded contexts, aggregates, entities, and value objects.
  • Teams model domains collaboratively with domain experts using tools like Event Storming or Domain Storytelling.
  • Strategic design involves identifying subdomains, their value, and appropriate architectural boundaries.
  • DDD supports microservices, modular monoliths, and event-driven systems by clarifying ownership and boundaries.

How to Practise It (Playbook)

1. Getting Started

  • Identify a core product or service area with unclear or complex business logic.
  • Facilitate a domain modelling workshop (e.g. Event Storming) with engineers and business experts.
  • Define a ubiquitous language - shared terms for domain concepts used in both code and conversation.
  • Map out bounded contexts and clarify their ownership, APIs, and interfaces.

2. Scaling and Maturing

  • Align teams and services to bounded contexts using tools like Team Topologies.
  • Apply tactical design patterns (e.g. aggregates, repositories, services) within each context.
  • Link domain events to analytics and observability systems to track business impact.
  • Refine the model iteratively as business needs evolve - treat DDD as a living practice.
  • Embed domain language and understanding in code, tests, and documentation.

3. Team Behaviours to Encourage

  • Collaborate regularly with domain experts - avoid building in isolation.
  • Use whiteboards, diagrams, and modelling sessions to co-create shared understanding.
  • Reflect on whether technical models match the business - refactor when they don’t.
  • Prefer clarity and alignment over abstract purity - pragmatic DDD wins.

4. Watch Out For…

  • Overcomplicating small systems with unnecessary DDD constructs.
  • Confusing tactical patterns (e.g. entities) with the strategic purpose of DDD.
  • Fragmented models and terminology across teams or systems.
  • Failing to keep the domain model aligned with actual business evolution.

5. Signals of Success

  • Teams speak a shared language with domain experts.
  • System boundaries reflect real business constraints and capabilities.
  • Code is expressive, maintainable, and aligned to business intent.
  • Changes in the domain are reflected quickly and cleanly in the architecture.
  • Engineering decisions are guided by domain understanding, not just technical trends.