Applying Domain-Driven Design to Refactor a Hotel Pricing System

Domain-Driven Design (DDD) is a system‑architecture method that separates technical complexity from business concepts, aiming to build a domain model that controls business complexity.

The hotel pricing system at Qunar suffered from tight coupling, low development efficiency, and tangled core and edge business logic, caused by unclear domain boundaries and rapid, varied requirements.

To address these issues, the team applied DDD in three stages: strategic design (brainstorming with domain experts to define business scenarios and prune unnecessary features), tactical design (building a layered architecture—User Interface, Application Core, Infrastructure—based on clean‑architecture principles), and system implementation (standardizing processes, abstracting business rules into SPU‑SKU models, and creating visual debugging tools).

Strategic design involved extracting core business plays such as “three‑party price limit”, “marketing promotions”, “benefit cloud”, and “sell‑back”, and establishing a business‑atom principle to delineate domain boundaries.

Tactical design introduced a layered architecture with clear responsibilities, adopted SPU‑SKU standardization, and defined coding conventions that favored “convention over configuration” while omitting CQRS command side because pricing is a read‑only calculation.

Implementation included comprehensive documentation, automated test refactoring from interface‑level to module‑level, and a visual debugging tool that outputs the full pricing context, reducing issue‑resolution time by over 90%.

The three‑month refactor was completed in 1.5 months, delivering a clearer architecture, faster feature adaptation, improved operational visibility, and stronger collaboration between product, engineering, and operations.

Overall, DDD helped the team clarify domain boundaries, restructure the backend architecture, and achieve a win‑win outcome for both business and technical teams.