Domain Event Lifecycle Architect

Wrote docs/architecture/domain-event-architect/00-overview/domain-event-architect-overview.md and docs/architecture/domain-event-architect/verification/fitness-self-check.md. Complete domain event architecture specification establishing immutable business-fact contracts, causal lineage, minimum semantic payloads, and context-to-integration translation boundaries.

---

skill: domain-event-architect

Domain Event Lifecycle Architecture: Commercial Lending & Clearing [DE-ARCH-001]

Summary

This specification establishes the domain event architecture, business-fact lifecycle governance, and integration event translation boundaries for the Commercial Lending & Treasury Clearing Engine under run ID lending-clearing-events-001. It governs 14,000 transaction events/second across Loan Origination, Treasury Clearing, and Credit Risk Monitoring contexts. It decisively resolves the event semantic drift and data corruption demonstrated in incident INC-4923 (where downstream risk monitoring mistook transient UI draft saves and generic LoanUpdated notifications for committed commercial disbursements, triggering $2.6M in uncollateralized loan extensions).

The architecture establishes

1. Strict past-tense business-fact event classification distinguishing internal domain events from public integration events, commands, and telemetry;
2. Immutable causal and temporal lineage (event_id, occurred_at, committed_at, aggregate_version, causation_id, correlation_id);
3. Minimum semantic payloads omitting internal entity graphs, mutable aggregate state, and sensitive credentials;
4. Explicit Domain-to-Integration Translation (Anti-Corruption Layers and Published Language adapters) preventing internal domain model leakage to external contexts.

Detailed Description

Emitting raw entity mutation snapshots (EntityCreated, EntityUpdated) or re-purposing rejectable commands as events creates catastrophic coupling across microservice boundaries. When events carry mutable aggregate graphs or lack explicit causal lineage, consumers make unsafe domain assumptions or process out-of-order state transitions. Domain events must represent immutable facts accepted by an aggregate root within its transaction boundary.

Commercial Lending Context (Aggregate: CommercialLoanFacility)
 ├── Command Handled: ApproveLoanFacilityCommand
 ├── ACID State Commit: Status -> APPROVED, Version -> 4
 └── Emits Domain Fact: `LoanFacilityApproved` [MSG-DE-01]
       │
       ▼ (Transactional Outbox Commit in Local ACID Boundary)
 [ Local Outbox Relay ]
       │
       ├──────────────────────────────┬──────────────────────────────┐
       ▼ (Internal Context Consumer)  ▼ (ACL Translation)            ▼ (Public Published Language)
 [ InterestAccrualProjection ]  [ Treasury Clearing Adapter ]  [ Integration Event Mesh ]
   ├── Read-Model Update          ├── Maps to Inbound Command    ├── `LoanFacilityMaturedIntegrationEvent`
   └── Idempotent Consumer        └── `InitiateWireDisbursement` └── Zero Leaked Internal Entities

Alternatives rejected

Contracts and Invariants

Immutable Business Fact Invariant [INV-DE-01]
  Domain events must be named in context-specific past tense representing finalized, committed business facts.
  Emitting prospective commands, mutable status flags, or generic CRUD update labels as domain events is strictly prohibited.

Minimum Semantic Payload & Encapsulation [INV-DE-02]
  Domain event payloads must contain only attributes necessary to represent the occurred fact and satisfy within-context
  policies. Leaking internal aggregate entity graphs, database schema columns, or plaintext secrets is prohibited.

Causal Lineage and Ordering Scope [INV-DE-03]
  Every domain event must record `event_id`, `aggregate_id`, `aggregate_version`, `occurred_at`, `committed_at`,
  `causation_id`, and `correlation_id`. Strict monotonic sequence ordering is guaranteed per aggregate root instance.

Isolated Integration Contract Boundary [INV-DE-04]
  Internal domain events must never be exposed across bounded context boundaries directly. Cross-context communication
  must transit explicitly versioned Integration Events published through an Anti-Corruption Layer.

Ownership and Handoffs

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against domain event architecture standards:

Fact Semantics: PASS. Every event represents an accepted past-tense business fact (LoanFacilityApproved, DisbursementSettled).

• Identity & Causality: PASS. Causal chains, monotonic sequence versions, and aggregate keys formally mandated.
• Encapsulation: PASS. Zero internal aggregate entity leakage; distinct integration event translation enforced.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-DE-01: Elena Rostova to determine whether Schema Registry Avro or Protobuf 3 serialization should be standard for external integration events in Q2 (Owner: Elena Rostova).

Next steps

1. Marcus Vance ratifies the domain event catalog schemas for LoanFacilityApproved and DisbursementSettled.
2. Platform team provisions Kafka topics partitioned by loan_facility_id with 7-day retention.
3. Treasury Clearing team deploys Anti-Corruption Layer translation adapters for cross-context integration events.

---

skill: domain-event-architect

Commercial Lending & Clearing Domain Events — Fitness Self-Check [DE-FIT-001]

Summary

This fitness self-check evaluates the domain event 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

• Transient outbox CDC polling lag (up to 45 ms) under sudden 20,000 event/sec burst spikes. Accepted by Elena Rostova with downstream consumer buffer sizing.

Traceability

Verification

No validator was supplied, so no command was run.

Open Decisions

None.

Next steps

1. Integrate synthetic probes FIT-1, FIT-2, and FIT-3 into CI pipeline pull request gates.
2. Conduct staging load drill simulating 14,000 events/sec to verify sub-50ms outbox delivery latency.
3. Establish monthly event schema governance reviews with Elena Rostova and context team leads.