Domain-Driven Design in Orchestrating Microservices - Introduction and Evaluation in an Existing Service.
Does DDD still pay off inside a single service that mostly just orchestrates others - and where does it stop paying?
stack · java · spring modulith · jmolecules · archunit · hexagonal architecture
abstract
DDD is usually studied as a way to cut a system into microservices. This thesis looks one level down: is it worth introducing into the internal structure of an existing, mostly orchestrating service with little domain logic of its own? Single-case study on a production service - one representative flow rebuilt as a full vertical slice (value objects, ports & adapters, an anti-corruption layer, a domain-oriented module cut), enforced in code with Spring Modulith and jMolecules, every design decision recorded as an ADR, and evaluated with before/after metrics plus qualitative criteria.
key findings
- Architecture rules went from convention to a build-enforced invariant - module verification now runs green on every build.
- A first genuinely domain-oriented module, with domain rules testable in isolation against ports instead of simulated downstream services.
- Four of the six tactical building blocks - entity, aggregate, repository, domain event - had nothing to hold on to without persistent domain state or real invariants, and were deliberately left out.
- The structure isn't free: with thin domain logic, the overhead per line of business code is clearly noticeable.
so what
Worth it, but not wall-to-wall. Model where the real domain rules live and leave pure pass-through paths alone. For an orchestrator the win isn't less coupling to the systems it calls - it's making that coupling explicit and controlled.
note · the full text is under a confidentiality notice.