How DDD Transforms Complex Marketing Systems: Strategic and Tactical Design Insights

Background

Marketing activities are essential for acquiring, retaining, and activating customers. Building a merchant‑focused marketing system at Meituan required handling massive business volume, diverse scenarios, complex customer structures, and constantly changing requirements. To manage this complexity the team adopted Domain‑Driven Design (DDD) to reduce obscurity, coupling, and frequent change.

Basic Concepts of Software Complexity

Obscurity : Understanding is hard when abstract layers and implementation details are not shared.

Coupling : Tight code, module, or system coupling expands the impact of changes.

Change : Business evolution forces frequent adjustments.

DDD provides a systematic way to tame these three dimensions by aligning the model with the business domain.

Strategic Design Practice

Strategic design starts with defining use cases and establishing a unified language and bounded contexts.

Use‑case diagram : Visualizes user‑system interactions.

User stories : Capture requirements from Who, What, Why.

Interaction prototypes : Show UI flow but may ignore business rules.

Event storming : Deeply uncovers business rules, suitable for large, complex domains.

Iterating these artifacts produced a use‑case diagram covering activities, coupons, inventory, tiers, and target audiences.

Concept extraction proceeds in three steps:

Identify concepts from use cases.

Adopt the business terminology for each concept.

Define a term (English name) and a precise meaning, forming a unified language.

Relationships (1‑to‑1, many‑to‑1, many‑to‑many) are modelled to create a concept model that guides tactical design. A shared language enables product, business, and technical teams to stay aligned.

Tactical Design Practice

Mapping the concept model to a code model involves:

Layered concepts: a generic MarketingActivity is specialized into sub‑activities such as RechargeGift or BuyGift.

Object composition: an activity aggregates Tier and Inventory objects.

Attributes become class fields; behaviors become methods; state machines become object state machines.

Two fundamental object types are distinguished:

Entity : has a unique identifier and lifecycle.

Value Object : immutable, identified solely by its attributes.

Aggregates encapsulate related objects. Two aggregate strategies were evaluated:

Small aggregates : each object has its own root, simplifying the model but requiring domain services when business rules cross aggregates (e.g., inventory affecting activity status).

Large aggregate root : groups Activity, Inventory, Tier, TierItem, and TargetAudience into a single root, trading higher loading cost for stronger consistency.

Aggregate design principles:

Guarantee business consistency, data completeness, and state integrity.

Respect technical constraints such as data volume.

Balance encapsulation with clear responsibility distribution.

Code Architecture Practice

Regardless of hexagonal, clean, or onion architecture, the domain model sits at the centre. Application and infrastructure layers depend on the domain. In the team’s implementation the domain and application layers are colocated (both contain domain logic), while infrastructure and user‑interface layers depend on them.

Summary of Lessons

Leverage existing industry practices; inventing new concepts is rarely necessary.

A unified language is essential—without it, concept models and reliable code models cannot be built.

DDD is a collaborative effort; any team member can become a domain expert.

Embrace continuous change; models evolve as business understanding deepens.

Typical pitfalls include over‑engineering DDD terminology, trying to design a perfect model upfront, and assuming DDD automatically yields a good model. Effective modeling follows the pipeline: functional model (use cases) → concept model (unified language) → code model (objects) → data model (tables).

References

"Domain‑Driven Design" – Eric Evans

"Implementing Domain‑Driven Design" – Vaughn Vernon

"Enterprise Application Architecture Patterns" – Martin Fowler

"The Clean Architecture" – Robert C. Martin

"The Onion Architecture" – Jeffrey Palermo

Software complexity article: https://carlalexander.ca/what-is-software-complexity/ Bounded Context (Martin Fowler):

https://martinfowler.com/bliki/BoundedContext.html