Domain-Driven Design (DDD) Practice in Hotel Data System Refactoring at Qunar

The author, Li Quandai, a senior technical manager at Qunar, introduces his background and the context of the hotel supply‑chain project, which involved modernizing a 10‑year‑old system composed of over 20 tightly coupled microservices.

Case Overview : Due to strategic shifts and rapid business growth, the legacy hotel data platform suffered from poor flexibility, unclear boundaries, and low development efficiency. In early 2022, the team initiated a DDD‑driven architectural overhaul to address these challenges.

Problem Analysis : Complex business requirements caused tangled logic and frequent scope changes. Excessive coupling among more than 20 microservices made even minor feature changes time‑consuming and risky. A typical workflow for adding hotel images required coordination across four different systems, taking 8 person‑days (estimated) but actually 11 person‑days.

Why DDD? DDD aligns business and system architecture, reduces software complexity, and provides a natural way to split microservices. It offers three main benefits: divide‑and‑conquer, separation of concerns, and a ubiquitous language.

Microservice Best Practices : By using aggregates and bounded contexts, the team could define clear service boundaries, avoiding the common pitfalls of unclear domain limits.

Evolutionary Technical Transformation : Instead of a full rewrite, the team adopted an incremental refactoring approach, preserving external functionality while gradually improving internal structure, thus minimizing risk and maintaining business continuity.

DDD Implementation Framework : The article shows a complete DDD rollout framework (adapted from ThoughtWorks) and emphasizes key practice principles such as: Vision alignment between product and engineering. Collaborative domain modeling with product, operations, and QA. Focusing resources on core domains while treating supporting domains as peripheral. Using bounded contexts to protect domain models. Adopting the COLA layered architecture (Adapter, Application Service, Domain Service, Infrastructure) to separate concerns.

Results : Business cases reduced from 188 to 109 (42% reduction), simplifying development. Microservices decreased from 21 to 13 (33% reduction) and code size dropped by ~58%. Two dedicated domain experts were added, improving domain knowledge. Incident handling time fell by 50%.

Common Issues & Solutions : The article discusses lack of domain experts, over‑engineering simple problems, non‑core domain distraction, and product focus on delivery speed over architectural quality, offering practical mitigation strategies.

Conclusion : DDD is a mindset and methodology that requires deep business‑technical collaboration; when applied thoughtfully, it can dramatically improve system modularity, reduce complexity, and accelerate delivery, though it is not a silver bullet.