Applying Domain‑Driven Design (DDD) to Microservice Decomposition

In recent years microservice decomposition has become a mainstream practice. While many teams abandon monolithic architectures, they soon encounter new problems such as tangled service‑to‑service logic, increased operational complexity, and the emergence of a "big mudball" architecture.

This article explains how to use Domain‑Driven Design (DDD) to guide microservice splitting. It first introduces DDD, its origins, and why it is especially useful when breaking down monoliths into services.

Advantages of DDD include providing a unified language for business and technical teams, enabling strategic design of core, generic, and supporting domains, and reducing the risk of retry storms and circular dependencies.

The article then presents a concrete example – a membership center – to illustrate strategic design, tactical design, and code implementation.

Strategic Design divides the business into three domain types:

Core domain: the most important business functions (e.g., traffic acquisition or monetisation).

Supporting domain: non‑core functions that support the core domain.

Generic domain: shared capabilities such as authentication, verification, or payment.

Boundary definition follows the principle of "if you cannot clearly define a boundary, do not split yet" and stresses a top‑down layering where upstream services only depend on downstream services.

Tactical Design introduces key DDD building blocks:

Aggregates and aggregate roots – the smallest unit for service splitting, ensuring high cohesion and low coupling.

Entities – objects with a global identifier and lifecycle.

Value objects – immutable data carriers without identity.

Domain services – behaviours that do not belong to a specific entity.

Domain events – modeling of significant business occurrences.

Below is a simplified Go definition of the EntityVipCode aggregate root:

type EntityVipCode struct {
    ValidityStart *time.Time // 绑码开始时间
    ValidityEnd   *time.Time // 绑定会员码结束时间
    OrderInfo     *VOOrderInfo // 订单信息值对象
    BuyerInfo     *VOCodeBuyerInfo // 买会员码机构信息
    PrivilegeInfo *VOPrivilege // 会员码包含的权益
}

The article also shows how the DDD principle of dependency inversion is applied when creating an order:

// ReqCreateOrder creates an order
func ReqCreateOrder(ctx context.Context, vipRepo repository.IVipCodeRepo, vipcodeentity vipcode.EntityVipCode) (*order.PreorderRetData, error) {
    // implementation omitted
}

type IVipCodeRepo interface {
    CreateOrder(ctx context.Context, ev vipcode.EntityVipCode) (*liborder.PreorderRetData, error)
    UpdateVipCode(ctx context.Context, patch map[string]interface{}, conditions map[string]interface{}) (int64, error)
}

The project follows a four‑layer DDD architecture (interface, application, domain, infrastructure). The directory structures are shown below.

|-- interface
|   |-- command // batch processing interfaces
|   |   |-- controller
|   |   |   |-- vip
|   |   |       |-- add.go
|   |   |       `-- update.go
|   |   |-- router.go // entry point
|   |   `-- script.go
|   `-- http // API layer
|       |-- controller // request validation and routing
|       |   |-- lawyer
|       |   |   |-- add.go
|       |   |   `-- update.go
|       |   `-- vipcode
|       |       |-- add.go
|       |       `-- update.go
|       `-- router.go // API router

Application layer:

|-- application
|   |-- service // application services
|   |   |-- lawyer
|   |   |   |-- add.go
|   |   |   `-- update.go
|   |   `-- vip
|   |       |-- add.go
|   |       `-- update.go
|   `-- viewmodel // view models
|       |-- lawyer
|       |   |-- transform.go
|       |   `-- vm.go
|       `-- vip
|           |-- transform.go
|           `-- vm.go

Domain layer (core business logic):

|-- domain
|   |-- aggregate // aggregates, entities, value objects
|   |   |-- lawyer
|   |   |   |-- entity.go
|   |   |   `-- vo.go
|   |   `-- vipcode
|   |       |-- entity.go
|   |       `-- vo.go
|   |-- event // domain events
|   |   `-- vipcode
|   |       `-- order.go
|   |-- repository // repository interfaces
|   |   |-- lawyer.go
|   |   `-- vipcode.go
|   |-- adaptor // anti‑corruption layer
|   |   `-- sms.go
|   `-- service // domain services
|       |-- lawyer
|       |   `-- vipcode.go
|       `-- vipcode
|           `-- vipcode.go

Infrastructure layer (persistence, RPC, event handling):

|-- infrastructure
|   |-- event // event implementations
|   |   |-- init.go
|   |   `-- vipcode
|   |       `-- consume_order.go
|   |-- persistence // database persistence
|   |   |-- init.go
|   |   |-- lawyer
|   |   |   |-- po.go
|   |   |   |-- repo.go
|   |   |   `-- transform.go
|   |   `-- vipcode
|   |       |-- po.go
|   |       |-- repo.go
|   |       `-- transform.go
|   `-- rpc // RPC calls
|       |-- db
|       |-- init.go
|       `-- redis

The article concludes that DDD is most beneficial for large, complex business domains. For small, simple microservices, traditional MVC may be sufficient, and forcing DDD can increase workload. The key takeaway is that DDD aligns strategic product planning with tactical code design, turning design into code and vice‑versa.