How to Layer Microservices with DDD for Scalable Java E‑Commerce

1. Abstract

This paper presents a practice of applying layered design and DDD domain concepts to a microservice architecture for a Java fresh‑food e‑commerce platform. It proposes five layers—Infrastructure, Domain Service, Application Service, Gateway, and User Interface—showing how domain‑driven microservices simplify large systems and improve long‑term maintainability.

2. Background

Inspired by early experiences with simple business and presentation layers, the author adopted DDD after 2014, recognizing the need for a unified model language across product, project, architecture, and development teams. While DDD originated before microservices, both aim to manage complexity in large software systems.

3. Layered Design

The recommended five‑layer architecture consists of:

User Interface Layer: presents data to users or other systems.

Gateway Layer: provides external HTTP or application‑level protocol services, handling security, monitoring, and routing.

Application Service Layer: orchestrates tasks, delegates to domain objects, and remains free of business rules.

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

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

Key principles include keeping each layer cohesive, allowing only downward dependencies, communicating between layers via indirect mechanisms, and maintaining loose coupling.

4. Domain Partitioning and Microserviceization

Domain modeling occurs in the Domain Service layer; each domain module becomes a highly cohesive microservice. The article shares practical insights on defining clear functional boundaries, incremental splitting from monolith to microservices, and avoiding the “SMART UI” anti‑pattern.

5. Q&A

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

Using a single DB model (e.g., MyBatis‑generated POJOs) throughout violates the “one model per layer” principle, leading to data leakage, bloated contracts, and tight coupling. Separate DTOs, domain models, and persistence objects preserve encapsulation and flexibility.

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

The Application layer isolates business logic from external concerns, enabling better API design, security handling, and composition of multiple domain services into cohesive business use cases.

6. Conclusion

Applying a layered microservice architecture with DDD to a Java fresh‑food e‑commerce platform provides a reusable blueprint for building scalable, maintainable systems. The author hopes the shared experience helps teams design robust service‑oriented solutions.