Applying Domain-Driven Design (DDD) to Hotel Transaction Systems: Architecture and Code Implementation

The author, Li Xin, a senior software engineer at Qunar responsible for the domestic hotel transaction team, introduces his background and expertise in high‑concurrency, micro‑service systems and domain‑driven design.

The presentation focuses on the practical implementation of DDD in hotel transaction scenarios, linking the theoretical concepts from a previous article to concrete code.

Four‑layer DDD architecture : The system is divided into User Interface, Application, Domain, and Infrastructure layers. The UI layer handles rendering and user requests without business logic; the Application layer coordinates transactions and security, delegating to domain objects; the Domain layer encapsulates business concepts, rules, and aggregates; the Infrastructure layer provides persistence and other technical services.

The article distinguishes strict layering (only adjacent layers may couple) from loose layering (any upper layer may interact with any lower layer), noting that most real‑world systems adopt the latter to allow UI and services to work directly with infrastructure.

Code implementation examples are provided for each layer:

UI layer: order protocol handling, command injection, and response rendering.

Application layer: lightweight services that receive UI input, retrieve aggregates from repositories, and invoke commands.

Domain layer: aggregate root implementation for orders, adhering to principles such as a single root per aggregate, explicit behavior interfaces, and use of factories for complex object creation.

Factory example: creates order aggregates while protecting internal state and hiding setters.

Entity example: defines unique identifiers, lifecycle, and business behavior for financial entities.

Repository (resource layer): offers methods to fetch aggregates by ID and to persist them, acting as a collection rather than a simple CRUD interface.

The article also outlines consistency principles:

Within an aggregate, strong consistency is ensured via version control and atomic updates.

Between aggregates, eventual consistency is achieved using message queues and domain events (e.g., order cancellation triggers audit and payment events).

A step‑by‑step flow demonstrates how an order cancellation request propagates through audit, order, and payment aggregates, illustrating event publishing and handling.

In summary, the article covers the construction of a common language for hotel transactions, detailed code implementations for each DDD layer, aggregate design rules, factory and entity patterns, repository standards, and strategies for maintaining both intra‑ and inter‑aggregate consistency.