Skip to content

STD-ARC-002: Domain Driven Design (DDD)

1. Context

To ensure the software remains a faithful "Digital Twin" of the business reality. We do not build "Apps"; we model "Domains".

2. The Standard (The Floor)

  • [MUST] Ubiquitous Language: Code names MUST match Domain concepts. If the expert says "Resident", the class is Resident, not User.
  • [MUST] Bounded Contexts: packages/modules/* are Bounded Contexts. They MUST enforce strict boundaries (no cross-domain DB joins).
  • [MUST] Aggregates: Transactional consistency boundaries. An Aggregate Root (e.g., Building) controls access to its internal entities (Unit).
  • [MUST] Domain Layers: Logic MUST reside in the Domain Layer (Entities/Services), not the Infrastructure Layer (DB/API).

3. Best Practices (The Path)

  • [SHOULD] Event Storming: Use Event Storming sessions as an "Interim Method" to discover boundaries before writing code.
  • [SHOULD] Value Objects: Prefer Value Objects (Immutable, defined by attributes) over Primitives. (e.g., EmailAddress class vs string).
  • [SHOULD] Domain Events: Use events (ResidentMovedIn) to decouple side-effects between domains.

4. Required Artifacts (The Blueprint)

To satisfy the Definition of Done (STD-PRD-002), complex features must produce:

  1. Context Map: Visualizing relationships (Upstream/Downstream).
  2. Entity Map: Defining the Aggregates and their invariants.
  3. Dictionary: A glossary of the Ubiquitous Language.

5. Architectural Patterns

  • [MUST] The Unified Core Pattern (The Three Engines):
  • The Unified Layer:
    • Request Engine: Generic Intake (Capture -> Triage). Configuration defines "Forms".
    • Order Engine: Generic Execution (Resource -> Fulfillment). Configuration defines "Flows".
    • Ledger Engine: Generic Accounting (Double Entry). Configuration defines "Accounts".
  • The Operational Layer (Configuration & UI):
    • Modules (e.g., "Maintenance", "HR", "Procurement") are essentially configurations of the Core Engines.
    • They define the Types (e.g., "Plumbing"), Workflows (e.g., "Assign Vendor"), and accounts.
  • Goal: Write the engine once, configure it for every department.

5. Version History

Version Date Author Change
1.0 2026-01-25 AI Established DDD Standard

Version History

Version Date Author Change
0.1.0 2026-01-26 Antigravity Initial Audit & Metadata Injection