Evolution and Practice of Domain-Driven Design (DDD) in Meituan Dianping Transaction System

1. Introduction

This article is compiled from Meituan Technology Salon Session 73, titled “Architecture Evolution and Practice Based on Domain-Driven Design (DDD)”. It introduces the core concepts of DDD, common design ideas, and illustrates the evolution of the Dianping transaction system using DDD.

2. Dianping Transaction Business Overview

The transaction business covers three scenarios: overseas travel, mall group‑buy, and content commercialization. In the Dianping app, users can purchase travel tickets, shop in mall channels, or buy creator‑generated content notes for promotion.

3. Overview of Domain‑Driven Design

3.1 What is DDD?

DDD is a software design method for handling complex business requirements. It separates the problem domain (“domain”) from the technical implementation (“design”) and uses the domain model as the system’s core.

3.2 Core Concepts

The article emphasizes two key concepts: “Ubiquitous Language” – a shared vocabulary across strategic, tactical, and code levels, and “Bounded Context” – the boundary that connects problem space with solution space.

3.3 DDD Process

DDD requires collaboration among business, product, development, and QA teams to iteratively refine the domain model, split the domain into core, supporting, and generic sub‑domains, and continuously evolve the ubiquitous language.

4. Evolution of the Dianping Transaction System

4.1 Simple Architecture Phase

Initially only the overseas travel booking scenario was supported. The system used a traditional MVC layered architecture with separate B‑end (merchant), C‑end (product), and order modules. This phase was fast but suffered from data‑driven design, duplicated PO objects, and low cohesion.

4.2 Microservice Phase

Business expansion introduced multiple product lines, increasing code volume, dependencies, and the need for high availability. The team adopted a microservice architecture, applying DDD principles (strategic design, bounded contexts) to split the system into independent services.

4.3 Platform Phase

Further business diversification (mall group‑buy, content commercialization) led to a platform‑centric approach. A core domain model for overseas travel was extended with plug‑in modules for other business lines, enabling reuse of platform capabilities.

5. DDD Implementation Steps

Understanding the Problem Domain : Analyze business value, extract a ubiquitous language, and divide the domain into core, supporting, and generic sub‑domains.

Identifying Bounded Contexts : Define context boundaries based on semantic and functional relevance, and map interactions via anti‑corruption layers and open host services.

Domain Modeling : Perform entity/value‑object identification, design aggregates, and model domain events for coordination.

Model Implementation : Map the model to layers (interface, application service, domain service, aggregate, infrastructure) and implement each bounded context as a microservice following SOLID and separation‑of‑concerns principles.

6. Summary and Reflections

DDD is an open‑ended methodology that emphasizes strategic design over tactical design, treats modeling as an iterative process, and can be applied with various architectural styles (clean, hexagonal, MVC) as long as business and technical complexities are properly separated.