How DDD Can Tame Complex Microservice Architectures

What is DDD?

DDD (Domain‑Driven Design) originated from Eric Evans' 2004 book and has become popular with the rise of microservices. It helps split monolithic applications into well‑bounded services.

Why use DDD for microservice splitting?

Microservice splitting often leads to complex inter‑service logic, retry storms, and reduced iteration efficiency. DDD guides business‑driven service decomposition, reducing risk and improving maintainability.

Benefits of DDD

Unified language eliminates misunderstandings between product, operations and developers.

Strategic design focuses on core, generic and supporting domains, aligning resources with product priorities.

Tactical design defines aggregates, entities, value objects, domain services and events.

Strategic Design Example – Membership Center

We divide the domain into core, generic and supporting sub‑domains. Core domain handles traffic acquisition, supporting domain handles ancillary functions, and generic domain provides common capabilities such as authentication.

Core domain: business‑critical features.

Supporting domain: non‑core features.

Generic domain: shared services like login, payment.

Boundary Definition

Use DDD to define bounded contexts; if unclear, postpone splitting.

Ensure upstream services only depend on downstream services to avoid call cycles and retry storms.

Core services must support fallback and disaster recovery.

Align service boundaries with team organization to limit communication overhead.

Tactical Design

Key concepts:

Aggregate and aggregate root : smallest unit for service splitting, high cohesion, low coupling.

Domain service : important business behavior not belonging to an entity.

Domain event : models events occurring in the domain.

Entity : has a global identifier and lifecycle.

Value object : identified by its attributes, immutable.

Code Implementation (Membership Service)

The project follows a four‑layer DDD architecture: interface, application, domain, and infrastructure.

Interface layer defines API contracts and batch commands.

Application layer orchestrates domain services and repositories.

Domain layer contains aggregates, entities, value objects, repositories, services and adapters.

Infrastructure layer implements persistence, RPC calls and event handling.

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

// ReqCreateOrder 创建订单
func ReqCreateOrder(ctx context.Context, vipRepo repository.IVipCodeRepo, vipcodeentity vipcode.EntityVipCode) (*order.PreorderRetData, error)

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)
}

Conclusion

DDD helps translate business models into object models, improving extensibility and maintainability for large, complex systems. It is not necessary for simple services where MVC suffices, and should be applied judiciously.