Skip to content

ADR-0009: Clean Architecture + DDD for services

Decision

This page records a decision and its status. A Proposed decision is not binding; an Accepted decision is binding on the Factory until amended or superseded.

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

Reviewed 2026-10-09 — retained, clarified

  • Disposition: retain.
  • Clarification: bounded contexts are ownership boundaries, not a rule of one service per catalog row. The 162-row service catalog is consolidated into an ownership map with one authoritative writer per capability; modules may share a host until extraction is justified.
  • Verified: BaseTemplate and MicroserviceTemplate enforce the layered layout; DerechHaLev's nine services follow it; the canonical ADR-00xx layering (Layer 1 NuGet, Layer 2 BaseTemplate submodule, Layer 3 overlays) is the composition mechanism.
  • Provenance: Date is the 2026-06-17 bulk-commit value.

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.