Designing Layered Microservices with DDD for a Java Fresh Food E‑Commerce Platform

1. Abstract

This paper presents a practical solution that combines layered design with DDD for microservice architecture, proposing a five‑layer stack—Infrastructure, Domain Service, Application Service, Gateway, and User Interface. The approach simplifies large systems, improves maintainability, and raises architectural demands on developers.

2. Background

After years of software engineering experience and exposure to DDD since 2014, the author realized that clear domain boundaries and layered separation are essential for complex platforms. Traditional monolithic servers are being replaced by microservices, and DDD provides a scientific method to design such systems.

3. Layered Design

The recommended layers are:

User Interface Layer: presents data to users or external systems and assembles front‑end data.

Gateway Layer: exposes HTTP or other application‑level protocols and handles security, monitoring, and routing.

Application Service Layer: coordinates domain objects to accomplish tasks without containing business rules.

Domain Service Layer: encapsulates business concepts, state, and rules; it is the core of the system.

Infrastructure Layer: provides generic technical capabilities such as persistence, middleware, and third‑party services.

Key principles include internal cohesion, dependency only on lower layers, indirect communication via middleware, and loose coupling between layers.

4. Domain Partitioning and Microserviceization

Domain modeling occurs in the Domain Service Layer, where each domain module becomes a highly cohesive microservice. The article shares real‑world examples of a fruit‑selling platform and its extension to a hardware‑selling system, illustrating how clear domain boundaries enable rapid feature expansion.

“The article focuses on applying DDD’s design philosophy rather than detailed modeling; both DDD and traditional anemic models can coexist within each microservice.”

Practical advice for domain splitting includes defining clear functional boundaries, incremental refinement, allowing multiple sub‑domains within a larger domain, and designing services independent of callers.

5. Q&A

5.1 Can the same persistence model be used across all layers?

No. Each layer should have its own model to avoid leaking sensitive data, reduce coupling, and respect the Law of Demeter. “One model per layer” promotes clear contracts and easier evolution.

5.2 Why keep an Application Service Layer instead of exposing Domain Services directly?

The Application Layer acts as a façade, translating domain‑level operations into API contracts, handling security, and preventing tight coupling between external callers and domain logic.

6. Conclusion

Layered microservice architecture with DDD provides a solid foundation for large Java e‑commerce platforms. The author hopes the shared experience helps teams design maintainable, scalable systems.