Using Domain-Driven Design to Split Microservices

In recent years, microservice decomposition has become popular, but many teams encounter problems such as complex inter‑service logic, high operational overhead, 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 advantages, and then shows how to perform business decomposition with a concrete membership‑center example, followed by a detailed code implementation.

Key DDD benefits include a unified language that eliminates misunderstandings between product, operations and developers, strategic design that separates core, generic and supporting domains, and tactical design that defines aggregates, entities, value objects, domain services and events.

Strategic design divides the system into core domains (business‑critical), generic domains (common capabilities such as authentication), and supporting domains, aligning development effort with product priorities.

Tactical design covers concepts such as aggregates (e.g., the VipCode aggregate), aggregate roots, entities, value objects, domain services and events, and shows how to model them in Go.

The article presents the project structure of a four‑layer DDD implementation (interface, application, domain, infrastructure) and provides sample Go code for the VipCode entity and repository interfaces.

Code example:

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

Another example shows the repository interface and a use‑case function that creates an order, illustrating the dependency‑inversion principle.

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

The conclusion emphasizes that DDD is most suitable for large, complex business scenarios; it helps translate business models into object models, improving extensibility and maintainability, but should not be forced onto simple services.