Hands‑On DDD in Go: Building a Microservice‑Based E‑Commerce System

Introduction

The piece concludes a DDD tutorial series and shifts focus to concrete implementation. A fictional e‑commerce system is used as the running example, divided into three bounded contexts—product, inventory, and order—each realized as an independent microservice.

Product context

Inventory context

Order context

All services are built with the Kitex framework, and their RPC contracts are defined via Thrift IDL files, illustrated in the following images.

01 Code Layering

A typical DDD four‑layer architecture is adopted: domain, application, infrastructure, and interfaces. The diagram below shows the package layout, including a dedicated config package for environment‑specific settings.

Interfaces to external resources (databases, message queues, etc.) are placed in an interfaces package, while concrete implementations live in infra. Repository interfaces stay in the domain layer to avoid coupling.

02 Domain Modeling and Persistence

Strategic design identifies entities, value objects, and aggregate roots. In the order service the value objects Address and Monetary are simple; the aggregate root OrderAggregate is defined as shown.

The second line makes OrderAggregate inherit from ddd.AggregateManager, which handles temporary event storage and snapshot‑based incremental updates.

AggregateManager

implements the AggregateRoot interface, so the aggregate can call event‑related methods directly.

The Items slice in the aggregate is tagged with trace:"items" to let the persistence layer know which rows need updating.

Before persisting, a converter transforms OrderAggregate into a plain data object ( OrderPO).

The repository implementation in the infrastructure layer follows the pattern shown below.

03 Business Logic Handling

DDD encourages placing business rules on entities and value objects, yielding a rich domain model. The order aggregate defines several methods (shown in the diagram) that both perform actions and return an error for validation.

Because order creation involves many parameters, a dedicated factory using the builder pattern is introduced. Each WithXXX method returns the factory itself, enabling fluent chaining.

The Create method assembles the final OrderAggregate, computing derived fields such as total price before returning the aggregate and any error.

After persisting, an OrderCreated domain event is emitted and an email is sent. These cross‑cutting concerns are encapsulated in a domain service whose dependencies are defined as interfaces in the interfaces package and implemented in infra.

04 Cross‑Cutting Concerns

Application services coordinate transactions, logging, and simply forward validated requests to domain services. The user‑interface layer, generated by Kitex, parses incoming RPC calls and passes the resulting data structures to the application services.

05 Conclusion

The article demonstrates a full DDD‑driven workflow for a simple e‑commerce scenario, reinforcing concepts from earlier posts such as value objects, entities, repositories, factories, and application services, and showing how they fit together in a production‑grade Go microservice architecture.