Case Study: DDD‑Driven Architectural Refactoring of the Hotel Pricing System at Qunar

Author Introduction Zheng Jimin joined Qunar in August 2019 as the technical director of the flight‑destination business unit, serving as a technical committee member and SIG leader, overseeing the hotel pricing center and business architecture group.

Case Overview The COVID‑19 pandemic forced a major reorganization of Qunar’s travel business, creating a combined flight‑hotel business group and exposing inefficiencies in the hotel pricing workflow, where product teams had to coordinate with multiple technical teams and the architecture was misaligned with business needs.

Background and Problems After merging flight and hotel divisions, the company aimed to enable cross‑selling of flights and hotels. However, the existing system suffered from fragmented team communication, unclear boundaries between application and domain layers, and a “Swiss‑army‑knife” architecture that worked only during rapid growth.

Problem Analysis 1 Key issues included the need for multiple team interactions per feature, frequent upgrades to technical solutions, long request chains, and a core pricing team that was too low‑level to handle front‑end integration.

Problem Analysis 2 Many teams maintained their own application layers, leading to duplicated responsibilities and a lack of clear ownership, which caused “no‑one‑does‑it” situations.

Explicit Architecture Analysis

The diagram, inspired by Herbert Graca’s “Clear Architecture”, combines DDD, Onion, Clean Architecture, and CQRS, emphasizing stable core domain layers, adaptable outer layers, clear boundaries, and low coupling.

Technical Architecture Concept

Adopt a DDD‑layered architecture with strict separation of application and domain layers.

Consolidate all application‑layer responsibilities into a unified “big‑front” team, allowing domain teams to focus on core business capabilities.

Architecture Adjustment Plan

The target architecture highlights a “big front” that aggregates domain services, reduces data‑flow length, and improves response times.

Advantages

Product teams interact with a single “big front” team, reducing coordination overhead.

Shorter core process chains simplify debugging and cut response time by 25%.

Disadvantages

Short‑term disruption as teams adapt to new data paths and responsibilities.

Potential instability in upstream teams handling miscellaneous tasks.

Implementation Steps

Reassign application‑layer ownership to the big‑front team.

Adjust organizational structure, merge gateway teams, and plan headcount changes.

Define data‑return standards for SPU and SKU dimensions.

Applying these standards reduced the number of applications in the core flow from seven to four and improved overall latency.

Request Handling Standardization

The team introduced a generic component called QShareData to share parameters across services without polluting APIs, improving traceability and reducing unnecessary data passing.

Case Summary

Conway’s Law states that system design mirrors organizational communication structures. By aligning the architecture with domain‑driven design, Qunar reshaped its teams to match business domains, creating a flexible, scalable system that can evolve with future business changes.

Key takeaways: use DDD to derive domain models, restructure teams accordingly, and maintain a mesh‑like organization that can adapt when business shifts.

END