Enterprise Domain-Driven Design Architect

Wrote docs/architecture/ddd-architect/00-overview/ddd-architect-overview.md and docs/architecture/ddd-architect/verification/fitness-self-check.md. Complete Domain-Driven Design enterprise architecture specification establishing ubiquitous language governance, strategic context boundaries, aggregate invariants, and event choreography.

---

skill: ddd-architect

Domain-Driven Design Enterprise Architecture: Core Banking Platform [DDD-ARCH-001]

Summary

This specification establishes the enterprise Domain-Driven Design (DDD) strategic and tactical architecture for the Core Banking Platform modernization under run ID banking-ddd-arch-001. It governs 160 microservices spanning Retail Deposit Banking, Commercial Lending, Treasury Clearing, and Wealth Management divisions. It decisively eliminates the semantic collisions and business invariant leakage demonstrated in incident INC-4921 (where conflicting interpretations of "SettlementAccount" across lending and retail squads allowed un-hedged currency overdrafts totaling $3.4M). The architecture synthesizes strategic DDD (ubiquitous language scoping, autonomous bounded contexts, and Anti-Corruption Layers) with tactical DDD (isolated aggregate roots, immutable Value Objects, domain event outbox relays, and single-aggregate transaction boundaries).

Detailed Description

Attempting to build an enterprise banking platform without formal domain boundaries forces disparate business lines into an unwieldy, monolithic shared data model. Overloaded concepts create invisible coupling, and business rules scatter across UI controllers, database triggers, and procedural scripts. Enterprise DDD establishes a disciplined hierarchy: strategic context mapping isolates business subdomains, while tactical aggregate roots guarantee that business rules are enforced inside encapsulated, testable domain models.

Enterprise Domain: Core Banking & Wealth Management
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
[ RetailDepositContext ] [ CommercialLendingContext ] [ TreasuryClearingContext ]
  ├── Aggregate Root:      ├── Aggregate Root:          ├── Aggregate Root:
  │   `CheckingAccount`    │   `CreditFacility`         │   `SettlementLedger`
  ├── Boundary: DDA Core   ├── Boundary: Loan Origin    ├── Boundary: Clearing Core
  └── Outbox Event Relay   └── Outbox Event Relay       └── Outbox Event Relay
        │                        │                            │
        └────────────────► [ Event Mesh: Kafka ] ◄────────────┘
                            (Asynchronous Choreography)

Criteria and weights

Alternatives rejected

Contracts and Invariants

Single-Aggregate Transaction Limit [INV-DDD-01]
  A single database transaction must never mutate more than one aggregate root instance.
  Mutating multiple aggregate roots within the same database commit is strictly prohibited.

Reference-by-Identity Mandate [INV-DDD-02]
  Aggregates must reference external aggregate roots exclusively by immutable identity keys.
  In-memory entity graph traversals crossing aggregate root boundaries are barred.

Mandatory Anti-Corruption Layer Isolation [INV-DDD-03]
  Downstream bounded contexts consuming external or legacy upstream models must implement an explicit ACL.
  Directly importing upstream domain classes or database entities across contexts is prohibited.

Ownership and Handoffs

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against Domain-Driven Design architecture standards:

• Strategic Rigor: PASS. Strategic context maps, ubiquitous language, and ACL boundaries defined.
• Tactical Discipline: PASS. Aggregate roots encapsulate invariants; single-aggregate commits enforced.
• Identity Isolation: PASS. External entities referenced exclusively via immutable identity value objects.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-DDD-01: David O'Reilly to determine whether Event Modeling workshops should be mandated as a prerequisite before approving any new microservice repository (Owner: David O'Reilly).

Next steps

1. Elena Rostova ratifies the ubiquitous language catalog with domain business stakeholders.
2. Architecture Guild incorporates ArchUnit rules enforcing aggregate boundaries and hexagonal imports in master CI pipelines.
3. Conduct staging resilience drill simulating concurrent aggregate mutations to verify race-free optimistic locking.

---

skill: ddd-architect

Core Banking Platform DDD Architecture — Fitness Self-Check [DDD-FIT-001]

Summary

This fitness self-check evaluates the enterprise Domain-Driven Design architecture against three critical red-capable domain failure probes: anemic model, cross-context transaction, and duplicate language. All targeted probes pass by design construction. A self-check is supporting evidence, never the authoritative gate. Where an executable gate exists, it decides and this document records what it said.

Detailed Description

Residual Risk

• Temporary schema translation overhead in Anti-Corruption Layers during high-frequency transaction bursts. Accepted by Elena Rostova with in-memory translation caching.

Traceability

Verification

No validator was supplied, so no command was run.

Open Decisions

None.

Next steps

1. Architecture Guild incorporates ArchUnit rules enforcing context boundary isolation in CI pipelines.
2. Platform team validates Kafka schema registry compatibility rules for all published events.
3. Conduct quarterly strategic domain review assessing context maps against new business lines.