Domain-Driven Design Aggregate Portfolio Architect

Wrote docs/architecture/aggregate-architect/00-overview/aggregate-architect-overview.md. Complete DDD aggregate portfolio architecture specification establishing consistency boundaries across 4 aggregates, asynchronous event choreography, and optimistic concurrency.

---

skill: aggregate-architect

Aggregate Portfolio Architecture: Global Wealth Platform [AGGPORT-WEALTH-001]

Summary

This specification establishes the enterprise Domain-Driven Design (DDD) aggregate portfolio architecture, transactional consistency boundaries, and inter-aggregate event choreography for the Global Wealth Portfolio & Trading Platform under run ID wealth-agg-arch-001. It governs 120,000 high-net-worth client accounts managing $45B in assets under management (AUM) across 14,000 transaction events/second. It decisively eliminates the database lock contention and cascading freezes demonstrated in incident DB-4921 (where multi-aggregate ACID database transactions on shared client records froze portfolio queries for 38 minutes during a market selloff, dropping $4.2M in trades). The architecture decomposes the domain into

four discrete aggregate roots (ClientPortfolio, TradeExecutionOrder, AssetAllocationPlan, CashSettlementAccount), enforces single-aggregate transactional consistency, connects aggregates via asynchronous Apache Kafka domain events, mandates optimistic concurrency versioning, and bounds cross-aggregate eventual consistency reconciliation to

<= 200 milliseconds.

Detailed Description

In complex financial domains, attempting to maintain immediate ACID consistency across multiple related domain entities results in massive database table locks and distributed deadlocks. When order placement, cash balance verification, and asset allocation recalculation are chained into a single synchronous transaction, a lock on a single cash balance record blocks portfolio rebalancing and trade execution across the entire account. An authoritative aggregate portfolio establishes isolated consistency islands, enforces strict reference-by-identity across roots, and coordinates state transitions through an asynchronous transactional outbox event mesh.

Client Rebalance Request (14,000 events/sec)
                         │
                         ▼
[ Aggregate 1: ClientPortfolio Root ] ── (ACID Commit in < 8 ms)
  ├── Enforces: Max Target Asset Class Weights (100% Total)
  └── Emits Domain Event: `RebalancePlanApproved` via Outbox
                         │
                         ▼ (Apache Kafka: Keyed by `portfolio_id`)
[ Aggregate 2: TradeExecutionOrder Root ] ── (ACID Commit in < 12 ms)
  ├── 1. Consumes `RebalancePlanApproved`
  ├── 2. Generates Sub-Orders (Market Equities, Fixed Income)
  └── 3. Emits Domain Event: `OrderSubmitted`
                         │
        ┌────────────────┴────────────────┐
        ▼ (Asynchronous Kafka Stream)     ▼ (Latency <= 200 ms)
[ Aggregate 3: CashSettlementAccount ]   [ Aggregate 4: AssetAllocationPlan ]
  ├── Reserves Available Cash Margin       ├── Rebalances Model Asset Drift
  └── Emits `FundsReservedEvent`           └── Emits `AllocationUpdatedEvent`

Criteria and weights

Comparison

Result

Option C is selected. Four isolated aggregates eliminate lock contention; transactional outbox publishing ensures reliable eventual consistency; optimistic locking guarantees race-free commits.

---

Required Mechanisms

1. Aggregate Portfolio Decomposition & Root Boundaries [MC-AP-01]

1. ClientPortfolio (Aggregate Root)

• Invariants: Total asset allocation target percentages must equal exactly

100.00%; portfolio risk tier must match KYC suitability score.

• Encapsulated Entities: PortfolioHolding (Instrument ID, Units Held, Cost Basis).

2. TradeExecutionOrder (Aggregate Root)

• Invariants: Order quantity must be $> 0$; limit price must be positive; order cannot be modified once state transitions to FILLED or ROUTED.
• Encapsulated Entities: OrderExecutionFill (Fill ID, Fill Price, Executed Units, Exchange Timestamp).

3. CashSettlementAccount (Aggregate Root)

• Invariants: Total settled cash minus reserved funds must be >=

0.00 (strict zero overdraft invariant for margin accounts).

• Encapsulated Entities: CashHoldReservation (Hold ID, Expire Epoch, Amount).

4. AssetAllocationPlan (Aggregate Root)

• Invariants: Rebalancing drift threshold must be between $1.00%$ and $15.00%$; rebalance frequency cannot exceed once per trading day.

2. Inter-Aggregate Event Choreography & Sagas [MC-EC-01]

• Choreography Pattern:
  1. ClientPortfolio commits target rebalance and publishes PortfolioRebalanceRequested.
  2. Order Saga Consumer intercepts event, commands CashSettlementAccount to reserve cash (ReserveFundsCommand).
  3. CashSettlementAccount commits local reservation and emits FundsReservedEvent.
  4. Order Saga initializes TradeExecutionOrder aggregate and routes orders to exchanges.
• Eventual Consistency SLA: End-to-end event choreography completes within <= 200 milliseconds at p99.

3. Reference-by-Identity Protocol [MC-RI-01]

• Direct object reference pointers between aggregates are strictly prohibited.
• Aggregates reference peer roots exclusively via immutable typed identity keys:
  • ClientPortfolio holds CashSettlementAccountId and AllocationPlanId.
  • TradeExecutionOrder holds ClientPortfolioId and CashHoldId.

4. Optimistic Concurrency Control [MC-OC-01]

• Every aggregate root table maintains an integer version column.
• Concurrent updates check: UPDATE ... WHERE id = :id AND version = :expected_version.
• If another thread mutated the aggregate concurrently, the transaction throws OptimisticLockingFailureException and triggers an automated exponential backoff retry (up to 3 attempts in < 50 ms).

---

Invariants and Contracts

Single-Aggregate Transaction Limit [INV-AGGPORT-01]
  A single database transaction must never mutate more than one aggregate root instance.
  Chaining multiple aggregate modifications into a shared ACID commit is prohibited.

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

Sub-Two-Hundred-Millisecond Convergence [INV-AGGPORT-03]
  Cross-aggregate state choreography orchestrated via domain events must achieve eventual consistency
  within 200 milliseconds under 14,000 events/second peak load.

Explicit Unknowns

• Kafka partition lag behavior when 12,000 portfolios rebalance simultaneously following an unscheduled Federal Reserve interest rate announcement (G-1).
• Outbox table CDC polling latency during sudden 50,000 record batch order execution bursts (G-2).

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against aggregate portfolio architecture standards:

• Boundary Cleanliness: PASS. Four discrete roots with zero shared tables or multi-root ACID commits.
• Identity Discipline: PASS. Aggregates reference peer entities exclusively by immutable ID strings.
• Event Choreography: PASS. Asynchronous Kafka event choreography replaces synchronous distributed 2PC.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-AGGPORT-01: Elena Rostova to determine whether Event Sourcing (EventStoreDB / ScyllaDB) should replace Aurora PostgreSQL for TradeExecutionOrder in Q1 (Owner: Elena Rostova).

Next steps

1. Marcus Vance provisions high-throughput Kafka topics partitioned by portfolio_id.
2. Engineering teams implement the four aggregate roots and transactional outbox tables in Java 21.
3. Conduct staging concurrency drill simulating 10,000 concurrent trade orders to verify race-free optimistic locking and sub-200ms reconciliation.