ADR-0009: Clean Architecture + DDD for services¶

Status: Accepted
Date: 2026-01-01
Deciders: Enterprise Architect, Application Architect
Tags: ddd, clean-architecture, services

Context¶

The factory generates many microservices across many bounded contexts, and they must be consistent, testable, and evolvable by agents. A uniform internal structure with clear domain boundaries is required so generation, review, and maintenance are predictable, and so domain logic stays isolated from infrastructure.

Decision¶

Structure every service with Clean Architecture layering (domain, application, infrastructure, presentation) and Domain-Driven Design tactical patterns (aggregate roots, entities, value objects, domain events, repositories). Bounded contexts and a ubiquitous language are first-class. Templates enforce this layout so generated code conforms by construction.

Consequences¶

Positive¶

Domain logic isolated and testable; infrastructure swappable.
Predictable structure for agent generation, review, and maintenance.

Negative / trade-offs¶

More upfront structure/boilerplate per service (mitigated by templates).

Neutral¶

Aggregate boundaries are documented per platform aggregate-roots.md.

Alternatives considered¶

Alternative	Why not chosen
Transaction-script / anemic models	Poor fit for complex domains; harder to evolve and reason about.
Per-service ad hoc structure	Defeats consistent generation and review.