Applying Domain-Driven Design to a B2B Marketing System: Strategic, Tactical, and Code Architecture Practices

1 Background

Marketing activities aim to acquire, retain, and activate customers; Meituan's local commerce team built a B2B marketing system facing large business volume, diverse scenarios, and rapidly changing requirements. The article uses Domain‑Driven Design (DDD) to address hidden complexity, coupling, and change.

2 Core Concepts

Software complexity stems from three aspects:

Obscurity : difficulty in understanding abstract or implementation details.

Coupling : code, module, and system level interdependencies increase modification cost.

Change : evolving business needs require frequent adjustments.

DDD helps mitigate these issues by providing a structured approach to model domains.

3 Strategic Design Practices

Strategic design starts with defining use cases through methods such as use‑case diagrams, user stories, interaction prototypes, and event storming. It then extracts concepts, establishes a ubiquitous language, and builds a concept model that captures relationships, attributes, and behaviors, enabling clear communication among business, product, and technical teams.

Bounded contexts and context mapping are used to align sub‑domains (e.g., activity, rights, audience, push, data) and to handle external concepts via anti‑corruption layers.

4 Tactical Design Practices

Tactical design maps the concept model to a code model, typically using object‑oriented techniques: inheritance for concept hierarchies, composition for relationships, and attributes/behaviors for properties. It distinguishes entities and value objects, determines aggregate roots (small vs. large), and applies principles to ensure business consistency, data integrity, and technical feasibility.

5 Code Architecture Practices

Regardless of the specific architectural style (hexagonal, clean, onion), the domain model sits at the core, with application services, infrastructure, and interfaces depending on it. The article shows how Meituan organizes its codebase, placing domain and application layers centrally and keeping infrastructure and UI layers peripheral.

6 Summary

Leverage existing industry practices; avoid inventing unnecessary concepts.

Prioritize a unified language to create reliable concept and code models.

DDD is a collaborative effort; the whole team must contribute to domain understanding.

Embrace continuous iteration as business and models evolve.

7 References

Key literature includes "Domain‑Driven Design" by Eric Evans, "Implementing Domain‑Driven Design" by Vaughn Vernon, and architectural patterns by Martin Fowler, Robert C. Martin, and Jeffrey Palermo.