Designing a Layered Microservice Architecture with DDD for Java E‑Commerce Platforms

1. Abstract

The article proposes a layered design combined with DDD concepts for a Java fresh‑food e‑commerce microservice architecture. It recommends five layers—Infrastructure, Domain Service, Application Service, Gateway, and User Interface—each with clear responsibilities, aiming to simplify large systems and improve long‑term maintainability.

2. Background

The author reflects on years of experience with module design, noting that without a systematic approach, designs become ad‑hoc and hard to evolve. After learning DDD in 2014, the author adopted its principles to achieve clearer domain boundaries. The discussion focuses on high‑level layering rather than detailed modeling or code‑level patterns.

3. Layered Design

Building on classic four‑layer architecture (Infrastructure, Domain, Application, Presentation), the author adds a Gateway layer to handle external HTTP exposure, security, and monitoring. The resulting five‑layer stack is:

User Interface Layer : Presents data to users or other systems; in front‑end/back‑end separation it assembles data for the front end.

Gateway Layer : Provides external HTTP or other application‑layer services, centralising security, rate‑limiting, and monitoring.

Application Service Layer : Orchestrates domain objects to accomplish business tasks; it contains no business rules, only coordination logic.

Domain Service Layer : Encapsulates core business concepts, state, and rules; each domain module becomes a highly cohesive microservice.

Infrastructure Layer : Supplies technical capabilities such as persistence, messaging, caching, and third‑party services.

The layers must obey three principles:

Each layer is internally cohesive and only depends on the layer directly below it.

Communication upward is mediated through indirect mechanisms (e.g., middleware).

Upper and lower layers remain loosely coupled, following the Dependency Inversion Principle.

Example diagrams illustrate the five‑layer stack and the responsibilities of each layer.

4. Domain Partitioning and Microserviceisation

Domain modelling occurs in the Domain Service layer; each domain module should be high‑cohesive and low‑coupled. The article does not delve into concrete DDD patterns (entities, aggregates, etc.) but stresses that a domain‑oriented microservice corresponds to a DDD module.

Practical advice for domain splitting includes:

Define clear functional boundaries for each domain (e.g., an Order domain groups creation, modification, and query operations).

Adopt incremental granularity: start with coarse modules and refine as requirements evolve.

Allow domains to consist of multiple sub‑domains or microservices; the number of services does not have to match the number of domains one‑to‑one.

Design domain services independent of callers, exposing generic operations rather than caller‑specific APIs.

5. Q&A

5.1 Should every layer share the same persistence model?

Using a single data‑object model (e.g., MyBatis‑generated POJOs) across all layers leads to over‑exposure of internal fields, violates the principle of least knowledge, and creates tight coupling. The author recommends a “one‑layer‑one‑model” approach, with explicit mapping between layers, avoiding tools like BeanUtils.copyProperties() that hide model boundaries.

5.2 Why keep an Application layer instead of exposing domain services directly through the gateway?

The Application layer acts as an orchestrator that composes multiple domain services into higher‑level business use cases, keeping domain services focused on core logic and allowing independent evolution of APIs.

6. Conclusion

For Java‑based fresh‑food e‑commerce platforms, a well‑structured microservice system—built on the five‑layer architecture and DDD‑driven domain partitioning—provides a solid foundation for future feature expansion and reduces the risk of project decay. The author hopes the shared experience helps practitioners design cleaner, more maintainable back‑ends.