Domain Driven Design

DDD

Modelling

  • Domain-Driven Design Starter Modelling Process (opens in a new tab)

    This process gives you a step-by-step guide for learning and practically applying each aspect of Domain-Driven Design (DDD) - from orienting around an organisation's business model to coding a domain model.

    Using this process will guide you through each of the essential steps in designing a software system with the DDD mindset, so you can focus on your business challenges and not be overwhelmed by learning DDD at the same time.

    Once you have been through a few iterations of the process you will have the foundational DDD theory and practical experience to go deeper into DDD. Then you will be able to adapt and improve the process to suit your needs in any context. On a real project you'll often be jumping back and forth between these steps.

  • The Bounded Context Canvas (opens in a new tab)

    The Bounded Context Canvas is a collaborative tool for designing and documenting the design of a single bounded context.

Process

Concepts

A domain is an area of knowledge associated with the problem we are trying to solve, or simply, that which a “domain expert” is expert in.

A omain Modelis a set of simplifications that represent those aspects of a domain that are relevant to a particular problem. The domain model is part of the solution space, while the domain that it represents is part of the problem space.

The Ubiquitous Language is a set of concepts and vocabulary that is associated with the domain and is shared by both the team members and the source code.

A bounded context is a subsystem in the solution space with clear boundaries that distinguish it from other subsystems. A bounded context often corresponds to a subdomain in the problem space. A bounded context also has its own set of concepts and vocabulary, its own dialect of the Ubiquitous Language.

A Context Map is a high-level diagram showing a collection of bounded contexts and the relationships between them.

A Domain Event is a record of something that happened in the system. It’s always described in the past tense. An event often triggers additional activity.

A Command is a request for some process to happen and is triggered by a person or another event. If the process succeeds, the state of the system changes and one or more Domain Events are recorded.

Guidelines

  • Focus on events and processes rather than data.
  • Partition the problem domain into smaller subdomains.
  • Create a model of each subdomain in the solution.
  • Develop an “everywhere language” that can be shared between everyone involved in the project.

Software Engineering

Toolkit

jMolecules

Spring Modulith

Case studies

PythonDriving in Australia