Summary of DDD Layered Architecture for the Bidding Team

DDD Layered Model Summary

DeWu Technology’s well‑known "Five‑Color Stone" project adopted Domain‑Driven Design (DDD) to redesign its business framework. After an initial MVC‑inspired version, the team iterated a second DDD refactor in August, gradually rolling out the new logic.

Interfaces (User Interface Layer)

The interfaces layer handles all traffic entry points, serving users (H5/APP), APIs, MQ, callbacks, automated tests, and batch scripts. Previously, only user calls were placed here, while other calls lived in the application layer, causing unclear layering and scattered entry points. Now all traffic is consolidated in interfaces.

Application (Application Service Layer)

This thin layer coordinates multiple domain aggregates to compose and orchestrate services. It should contain no business rules, only use‑case and workflow logic, and can call other microservices. Business logic belongs in the domain layer.

Example of a four‑step bidding process:

Call product API to verify the item is listed.

Validate bidding rules.

Persist data.

Call inventory API to generate stock.

The application layer orchestrates these steps; step 1 and 4 belong to the infrastructure layer, step 2 to the rule domain, and step 3 to the bidding domain.

Domain (Domain Service Layer)

The domain layer consists of aggregates implementing core business logic. It includes aggregates, entities, value objects, and domain services. Entities use the rich (active) model, encapsulating both data and behavior. Value objects represent concepts without unique identifiers.

Infrastructure (Infrastructure Layer)

This layer provides data access (DB, cache, external services) and isolates resource changes from the application and domain layers via dependency inversion. Changing a database only requires swapping the infrastructure implementation.

Anti‑Corruption Layer

Also called an adapter layer, it translates external context models into the current bounded context, preventing leakage of external parameters and reducing coupling.

Object Flow

Interfaces: request/response; Application: DTO; Domain: entity/VO; Infrastructure: PO.

Domain Events

Domain events decouple models, allowing asynchronous processing and eventual consistency. They can be published to message queues directly or stored for later dispatch.

Case: Sales Inventory Occupancy

The application layer orchestrates the process, while the domain layer handles core logic and persistence.

Document author: CJ BOYS