Applying Domain-Driven Design to Reduce Complexity in Ctrip's Car and Rental Services

Author Introduction

Xiaobai Long, senior backend engineer at Ctrip, focuses on architecture implementation and development efficiency.

Case Introduction

Ctrip's car‑hailing and rental (referred to as "Two‑Car") services faced increasing technical debt and system complexity due to evolving business scenarios, making understanding, maintenance, and iteration difficult.

The article describes how the team applied Domain‑Driven Design (DDD) to lower system complexity and the trade‑offs made during the refactoring of a legacy system.

Problem Analysis

2.1 Communication Difficulties – Communication between product, development, and cross‑team stakeholders consumed significant time, leading to misunderstandings and duplicated effort.

2.2 Unclear Business Boundaries – Over‑loading the Order entity with unrelated fields caused tight coupling, high release risk, and frequent failures when non‑order logic changed.

2.3 Difficulty Adapting to Business Changes – Embedded notification logic and other non‑core responsibilities made the order service brittle and hard to evolve.

Solution

3.1 Return to Business Essence – Vision – Define a clear product vision to guide future iterations and keep the system focused on core value.

3.2 Efficient Communication – Event Storming – Conduct event‑storming workshops (online or offline) to build a shared language, identify domain events, and map out business processes.

3.3 Bottom‑Up Sub‑Domain Division – Use Conway’s Law to align team boundaries with sub‑domains (e.g., User Order sub‑domain, Procurement sub‑domain, Payment sub‑domain).

3.4 Top‑Down Bounded Context Extraction – Identify bounded contexts such as User Order Context, Payment Fee Item Context, and User Notification Context to encapsulate domain knowledge.

3.5 Identify Context Dependencies – Apply the Conformist and Anti‑Corruption Layer patterns to manage interactions with external systems like the messaging platform.

Benefits Summary

4.1 Reduced Business Logic Coupling – Each domain now owns its data and rules, eliminating unnecessary fields in the Order entity.

4.2 Improved Team Efficiency – Clear domain‑team mapping resolves ownership disputes and streamlines collaboration.

4.3 Enhanced Performance and Stability – Field count reduced from 780+ to ~200, resulting in write latency dropping from 68 ms to 12 ms and read latency from 63 ms to 5 ms.

4.4 Data Consistency – Domains store their own data, preventing inconsistencies caused by cross‑domain writes.

4.5 Significant Labor Cost Reduction – Development effort decreased by 70‑80% for large projects due to decoupled architecture.

Challenges and Exploration

Key obstacles included scarcity of domain experts, urgent and numerous business demands, and limited DDD understanding within the team. Solutions involved leveraging senior developers as proxy experts, pre‑defining designs for incremental implementation, and establishing a dedicated DDD training group.