Domain‑Driven Design and Architecture for a Restaurant System: From Domain Modeling to Microservices

This article uses a restaurant scenario as a narrative backbone to illustrate domain‑driven design (DDD) and architectural principles, providing a full‑cycle case from domain analysis to implementation.

1. Domain Design

Domain design starts by abandoning a purely technical perspective and analyzing the problem from a pure business viewpoint, aiming for autonomy of business domains.

The restaurant is divided into business domains such as "Dish Domain", "Order Domain", "Kitchen Domain", and "Dining Domain" based on a macro process analysis.

Unified Language : Establish a ubiquitous language that clearly reflects business concepts, identifying roles, actions, and entities.

Use‑Case Analysis : Focus on the relationship between roles and actions without delving into detailed use‑case steps.

Domain Partitioning : Further split each macro domain by functional and role relevance, creating sub‑domains where appropriate (e.g., Procurement, Processing, Cooking within the Kitchen domain).

Domain Modeling : Identify core entities and their aggregates, distinguishing aggregation (weak relationship) from composition (strong relationship) to define the functional core.

Upstream‑Downstream Relationships : Define data flow influence rather than dependency or call relationships, specifying how upstream data prepares downstream processing.

2. Architecture Design

The architecture aims to manage complexity, volatility, and uncertainty, ensuring that changes in one part have minimal impact on others.

Three Principles : Suitability, Simplicity, Evolution.

2.1 Layered Architecture

Four layers are defined: Interface Layer (north‑bound gateway), Domain Use‑Case Layer (business logic), Domain Model Layer (entities, value objects, aggregates), Dependency Layer (south‑bound adapters), and Foundation Layer (technical utilities).

2.2 Architecture Mapping

Map business domains to architectural elements, ensuring one‑to‑one correspondence between domain and technical view (e.g., Kitchen as an application, Dish as a module).

2.3 Constraints

Lower layers must be stable and independent; upper layers may depend on them. Domain services and use‑case layers are the same; domain model layers must follow minimal dependency principles.

2.4 Microservice Partitioning

Microservices are derived from domain boundaries, respecting low coupling and high cohesion. The restaurant is split into Kitchen, Dish, and Order services, with a façade service for the restaurant front‑end and a foundation service for shared utilities.

3. Functional Design (Use‑Case Implementation)

Functional design translates the architectural blueprint into concrete features, ensuring that implementations follow the "open for extension, closed for modification" principle.

3.1 Concept of Function

Functions evolve; therefore, their definitions must be revisited and generalized (e.g., from "make fried rice" to "cook dishes").

3.2 Position of Use‑Cases

Validate that each new use‑case aligns with the established role‑domain relationships.

3.3 Event Storming

Use event‑storming to decompose complex functions into sub‑steps, identify participating roles, domains, and events.

3.4 Use‑Case Analysis

Identify commonalities and differences among use‑cases to enable reuse and extension.

3.5 Use‑Case Service Class Diagram

Design classes in the use‑case layer that encapsulate business rules while adhering to the open‑closed principle.

3.6 Use‑Case Flow Diagram

Map event‑storming outcomes to concrete class methods, illustrating the end‑to‑end business flow (often expressed as a swim‑lane diagram).

3.7 Activity / Sequence Diagram

Show dependencies and invocation order between domain entities and use‑case services, clarifying how the implementation realizes the designed flow.

4. Coding Implementation

The final coding stage follows the design artifacts to address software complexity, ensuring that developers produce consistent, maintainable code.

Happy holidays!