Rebuilding a Hotel Pricing Engine with Domain-Driven Design: A Qunar Case Study

After a post‑May Day tourism boom, Qunar faced significant pressure on its hotel pricing system, which had become complex, costly to maintain, and slow to incorporate new features.

Technical director Zheng Jimin highlighted the difficulty of maintaining the legacy pricing engine, noting long development cycles and steep learning curves for newcomers.

He introduced Domain‑Driven Design (DDD), explaining that it emphasizes building a domain model driven by deep business knowledge, separating technical complexity from business concepts to create a clearer, more evolvable architecture.

According to Zheng, DDD helps teams align product and engineering, clarify business boundaries, improve architecture, and ultimately boost overall efficiency and collaboration.

The refactor followed three stages: strategic design (principles such as simplicity, suitability, and evolutionary architecture), tactical design (high‑concurrency and high‑availability practices), and system implementation. The three‑month effort finished a day early and standardized many previously chaotic processes.

Quantitative results after the DDD‑based rebuild include:

Feature integration time reduced from ~5 person‑days to ~2 person‑days.

New‑developer onboarding cut from two months to two weeks, saving ~30 person‑days.

Weekly operational issue investigation time saved ~3 person‑days.

Product‑development communication time reduced by at least 0.5 person‑days per week.

Zheng emphasized that while the engine’s efficiency gains are clear, broader architectural adjustments are planned to extend DDD principles across Qunar’s hotel platform, separating core services from adaptable front‑end teams.

The article concludes with an invitation to Zheng’s upcoming SACC2021 talk titled “Hotel Pricing Engine Refactor Based on DDD” and a brief personal note about his love for travel and storytelling.