Which subdomain does the shop buy?

The payment, a generic subdomain. The payment provider is purchased, the shop translates its codes via an anti-corruption layer.

The shop introduces discount rules as a distinguishing feature compared to other shops. Where do they belong?

Into the core. Rules that distinguish the shop deserve deep modeling together with professionals, about close to the order.

The team wants to elaborately model the catalogue with aggregates and value objects. How do you rate that?

The catalogue is supportive. Elaborate modeling binds time that the core lacks. It would make sense to have a simple, solid implementation. If the catalogue grows into a distinguishing feature, more depth is worthwhile.

ApproachChapter I · Domain · Building block 1 of 7

Domain-Driven Design

Domain-Driven Design aligns software models with expertise and common language. Strategic boundaries and tactical models keep meanings and rules explicit.

By Michael Meierhoff · Meierhoff Systems

Core domainThe part that distinguishes the shop.
Common modelProfessionals and development share terms and rules.
Effort by valueThe less difference, the simpler.

Context

Why this is important

Professionals and development often understand the same thing differently. Eric Evans describes in “Domain-Driven Design” (“Domain-Driven Design”)2003), to model the core of the domain together first. Bounded context, aggregates and other resources deepen own building blocks.

This building block gives orientation about domain-driven design. For individual model boundaries see Bounded Context and for consistency limits see Aggregates.

At a glance · Shared language shapes the model

Domain experts and developers develop a shared language from which the core domain's model emerges.

Shop example · Subdomain card

Where does the shop invest modeling effort?

In the shop, not all modules are equally important. The order rules distinguish him, the payment he buys from the payment provider. The team then adjusts its modelling effort.

This is how you read the picture

Core domain Band “core”: Order with order and cancellation rules.
Common model At the core, the approach is: modeling together with experts.
Effort by value The bands from core to generic reduce the modelling effort.

CoreCore domain
This is where the business difference of the shop arises.
deeply model, together with experts
SupportiveSupporting Subdomain
Necessary for operation, but not a unique selling point.
simple and solid self-implementation
GenericGeneric subdomain
At many shops the same, hardly any own special feature.
Buying or using standard solution

OrderCore · deeply model, together with experts

Order and cancellation rules characterize the flow of the shop and carry the highest business risk.

Classification illustrative

Choose a module and read justification and handling; the classification is illustrative.

The DDD agents and where they are deepened

The DDD agents and where they are deepened
Question	DDD agents	Results in the shop
1. Which terms apply?	Ubiquitous Language	Order, reservation, authorisation
2. Where does a model apply?	Bounded Context	Order separately from invoice
3. How do models work together?	Context Map	Order provides invoice data
4. Which rules remain consistent?	Aggregate	Ordering protects position and status rules

Read from top to bottom: Each question leads to a DDD agent that deepens its own building block.

Benefits & limitations

Helps if:

Business rules and exceptions shape a product's value or risk.
Recurring misunderstandings between domain experts and developers lead to incorrect states or processes.

Boundaries

DDD needs regular access to domain experts. Without it, teams may retain only pattern names ('DDD lite': tactical patterns such as Aggregates without strategic boundaries) and lack a shared understanding.
DDD is not an architectural style and does not require microservices. The shop remains a Modular Monolith with modules organised around business responsibilities.

In practice

Identify the core domain. Determine which rules carry the greatest value or risk of failure. This establishes where collaborative modelling is worthwhile.
Explore terminology and rules through examples. Ask domain experts to explain typical flows, boundary cases and decision criteria. Anchor the terms in the model through Ubiquitous Language.
Carry the model into implementation and feedback. Use agreed rules in code, tests and reviews, updating them as new insights emerge. Keep distinct models separate through Bounded Context.

Read the detailed explanation

Domain experts and developers explore domain terminology, decisions and exceptions together. Their model is reflected in conversation, code and tests. Strategic modelling identifies business areas; tactical patterns shape behaviour and state within an area. Bounded Context defines a model's scope; Ubiquitous Language connects it to a shared vocabulary.

The effort focuses on business-critical areas where rules and changes carry high value or risk. The model evolves as new insights emerge. DDD is not a mandatory framework for every application and does not replace knowledge of users or clear technical boundaries.

Different parts of a domain merit different modelling effort: DDD distinguishes Core, Supporting and Generic Subdomains. In the shop, payment is generic and purchased from the payment provider. Business rules for orders form the core in which the team invests; Catalogue, Shopping Cart, Warehouse and Shipping are supporting subdomains implemented simply and reliably.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
Which subdomain does the shop buy?
View the solution with justification
The payment, a generic subdomain. The payment provider is purchased, the shop translates its codes via an anti-corruption layer.
ApplyingTransferred to a new situation
The shop introduces discount rules as a distinguishing feature compared to other shops. Where do they belong?
View the solution with justification
Into the core. Rules that distinguish the shop deserve deep modeling together with professionals, about close to the order.
EvaluateWeighing an alternative
The team wants to elaborately model the catalogue with aggregates and value objects. How do you rate that?
View the solution with justification
The catalogue is supportive. Elaborate modeling binds time that the core lacks. It would make sense to have a simple, solid implementation. If the catalogue grows into a distinguishing feature, more depth is worthwhile.

Explore further

These optional deepenings complement the learning goal of this page.

Event Storming

Event Storming is a collaborative exploration format: domain experts and developers place business events, named in the past tense, in chronological order, mark open questions and examine differing interpretations. In the shop, the sequence might be 'Order placed', 'Payment authorised', 'Stock reserved'. The outcome provides observations and modelling hypotheses; technical boundaries and communication styles are decided separately afterwards.

For testingExplore a shop order with domain experts. Arrange events such as 'Order placed' and 'Payment authorised' chronologically, mark open questions and resolve differences in meaning before defining model boundaries and technical implementation.

Domain Service

A Domain Service models a business rule or calculation that does not naturally belong to an Entity or Value Object. It uses domain language and receives the information it needs through explicit inputs or contracts. A Domain Service is neither a generic application step nor automatically a coordinator of distributed transactions; rules spanning consistency boundaries still need deliberate process coordination.

For testingExamine the shop's shipping eligibility rule. If it combines weight, delivery area and shipping method without belonging to one object, model it as a Domain Service with inputs named in domain language. Keep stock reservation and ordering as separate operations with their own results.

References

Continue on the learning path

Next in Domain modelling: Ubiquitous Language.

7 Building blocks

Continue withUbiquitous Language