How to Turn a Restaurant Scenario into Concrete DDD Architecture

1. Domain Design

The core of domain design is business‑driven decomposition, aiming to narrow the gap between the software system and real business to reduce related problems.

First, analyze the business thoroughly, then design a software model that corresponds to the business model – the essence of DDD.

1.1 Macro Process

When designing a restaurant, start from the macro process to quickly identify important functional areas, resulting in domains such as "Dish Domain", "Order Domain", "Kitchen Domain", and "Dining Domain".

1.2 Unified Language

A clear, shared language throughout the development process reflects precise business concepts.

Identify the core elements: Roles (actors), Actions (verbs), and Entities (nouns).

1.3 Use‑Case Analysis

Focus on the relationship between roles and actions to guide domain division and service design.

1.4 Domain Division

Based on functional relevance (golden standard) and, when necessary, role relevance, split the macro areas into finer domains while ensuring autonomy.

1.5 Domain Services

Domain services implement use‑cases and should be defined per role rather than per entity or aggregate.

Examples: Kitchen domain – Chef Service, Cutter Service, Purchaser Service; Dish domain – Customer Service, Manager Service.

1.6 Domain Modeling

Focus on business intent rather than merely data structures; avoid turning DDD into pure entity‑driven modeling.

First divide domains, then design services, and finally model entities, keeping the model as a means to realize use‑cases.

1.7 Aggregation vs. Composition

Aggregation is a weak relationship; composition is a strong lifecycle‑shared relationship.

1.8 Domain Upstream/Downstream

Upstream influences downstream via data flow; logical influence is secondary to data influence.

Different scenarios may have different upstream/downstream relationships, which should be documented per scenario.

2. Architecture Design

Architecture addresses system complexity by identifying elements and clarifying their relationships.

Three principles: suitability, simplicity, evolution.

2.1 Layered Architecture

Four layers: Interface Layer, Domain Use‑Case Layer, Domain Model Layer, Dependency Layer, and Foundation Layer.

Interface Layer : entry point, no business logic.

Domain Use‑Case Layer : implements business use‑cases, transaction boundary.

Domain Model Layer : holds entities, value objects, aggregates; pure domain capabilities.

Dependency Layer : connects external services, isolates domain from external tech.

Foundation Layer : generic technical utilities unrelated to business.

2.2 Architecture Mapping

Map business domains to architectural elements at matching granularity (system → application → module → sub‑module).

Ensure naming and hierarchy consistency between domain models and architecture components.

2.3 Constraints

Lower layers must be stable and not depend upward; domain services should follow OOP principles; interface and dependency layers must stay technology‑focused; domain layers must be autonomous and self‑contained.

2.4 Microservice Partitioning

Microservices should align with autonomous domains; e.g., a restaurant can be split into Kitchen, Dish, and Order services, while the Kitchen itself remains a single service due to tight coupling.

3. Functional Design (Use‑Case Implementation)

Functional design realizes the “open for extension, closed for modification” principle and provides concrete implementation guidance.

3.1 Concept of Function

Functions evolve; they must be abstracted and named appropriately (e.g., from "make fried rice" to "cook dishes").

3.2 Position of Use‑Cases

Place use‑cases in domains based on functional relevance and role relevance.

3.3 Event Storming

Use simplified event‑storming to break a function into steps, identify roles, sequence, domain events, and required entities.

3.4 Use‑Case Analysis

Identify commonalities and differences to enable reuse and extension.

3.5 Service Class Structure

Design domain service class diagrams that map roles to concrete service classes and methods.

3.6 Use‑Case Flow Diagram

Assign steps to service methods, link them with domain events, and visualize interactions via swim‑lane diagrams.

3.7 Activity / Sequence Diagram

Use sequence diagrams to show dependencies and calls between services and entities.

Through these three steps—domain design, architecture design, and functional design—the software system becomes a living documentation of the business, mapping "who", "where", "what", "impact", and "how" directly to code structures.