Strategic Bounded Context Portfolio Architect

Wrote docs/architecture/bounded-context-architect/00-overview/bounded-context-architect-overview.md and docs/architecture/bounded-context-architect/verification/fitness-self-check.md. Complete strategic Domain-Driven Design bounded context architecture specification establishing ubiquitous language boundaries across 3 banking domains, Anti-Corruption Layers, and team topology alignments.

skill: bounded-context-architect

Bounded Context Architecture: Retail Banking & Wealth Portfolio [BCARCH-FIN-001]

Summary

This specification establishes the strategic Domain-Driven Design (DDD) bounded context architecture, ubiquitous language boundaries, and context relationship topology for the Retail Banking & Wealth Modernization under run ID retail-wealth-bc-001. It governs 180 backend microservices across Retail Deposit Banking, Commercial Lending, and Wealth Management divisions. It decisively eliminates the catastrophic semantic collisions and schema fragility demonstrated in incident INC-4916 (where attempting to enforce a single canonical "Enterprise Data Model" caused an alter-table migration in Retail to silently break interest accrual algorithms in Commercial Lending for 3 weeks). The architecture partitions the enterprise into

three autonomous Bounded Contexts (RetailDepositContext, CommercialLendingContext, WealthManagementContext), eliminates polysemic concept ambiguity (Account and Balance), enforces

Anti-Corruption Layers (ACL) across legacy boundaries, and aligns context ownership with autonomous stream-aligned engineering teams.

Detailed Description

Attempting to model an entire enterprise under a single unified domain model is an anti-pattern. In reality, different business departments use the same linguistic terms to represent entirely different concepts. To a retail branch teller, an "Account" represents a demand deposit checking ledger. To a commercial loan officer, an "Account" represents a multi-party credit facility agreement with collateral liens. When these concepts are forced into a monolithic shared database table, schema changes in one division trigger unexpected breaking bugs in others. Strategic DDD isolates domain concepts within explicit contextual linguistic boundaries.

Enterprise Domain Boundary: Retail Banking & Wealth Management
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
[ RetailDepositContext ] [ CommercialLendingContext ] [ WealthManagementContext ]
  ├── Language:            ├── Language:                ├── Language:
  │   `CheckingAccount`    │   `CreditFacility`         │   `InvestmentPortfolio`
  ├── Model: Ledger DDA    ├── Model: Debt Instrument   ├── Model: Asset Allocation
  └── Boundary: DDA Core   └── Boundary: Loan Origin    └── Boundary: Portfolio Core
        │                        │                            │
        ▼ (Open Host Service)    ▼ (Downstream Consumer)      ▼ (Downstream Consumer)
  [ Ingress Gateway ] ────► [ Anti-Corruption Layer ] ──► [ Anti-Corruption Layer ]
  (Published Language)      (Translates DDA -> Loan)      (Translates DDA -> Wealth)

Criteria and weights

Alternatives rejected

Contracts and Invariants

Zero Cross-Context Database Sharing [INV-BCARCH-01]
  Bounded contexts must not share database schemas, tables, or connection pools.
  Cross-context data access must transit published APIs or asynchronous event streams.

Context-Bound Ubiquitous Language Invariant [INV-BCARCH-02]
  Domain entities within a context must strictly adhere to that context's ubiquitous language.
  Leaking foreign domain terminology (e.g. referencing `InvestorPortfolio` inside Lending) is barred.

Mandatory Anti-Corruption Layer Isolation [INV-BCARCH-03]
  Downstream contexts consuming external or legacy upstream models must implement an explicit ACL.
  Directly importing upstream domain classes or ORM entity jars across contexts is prohibited.

Ownership and Handoffs

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against bounded context architecture standards:

• Linguistic Precision: PASS. Disambiguates Account, Balance, and Customer across all 3 domains.
• Relationship Hygiene: PASS. Formally defines Customer-Supplier, OHS/PL, and ACL patterns.
• Database Decoupling: PASS. Strict prohibition of shared tables eliminates INC-4916 schema collisions.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-BCARCH-01: David O'Reilly to determine whether a shared Identity Context (IAM / SSO) should be classified as a generic subdomain Bounded Context or a shared platform utility (Owner: David O'Reilly).

Next steps

1. Elena Rostova publishes the ubiquitous language dictionaries to the enterprise architecture portal.
2. Commercial Lending team implements the RetailAccountToLoanAdapter ACL in their domain service.
3. Database Operations begins phased migration splitting legacy shared Oracle tables into isolated PostgreSQL databases per context.

skill: bounded-context-architect

Retail Banking & Wealth Bounded Contexts — Fitness Self-Check [BCARCH-FIN-FIT-001]

Summary

This fitness self-check evaluates the strategic Bounded Context architecture against three critical red-capable domain failure probes: shared mutable ownership, leaky abstraction, and implicit coupling. 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 duplication overhead when both Retail and Wealth independently maintain customer address records. Accepted by Elena Rostova with asynchronous Kafka event synchronization.

Traceability

Verification

No validator was supplied, so no command was run.

Open Decisions

None.

Next steps

1. Architecture Guild incorporates ArchUnit package rules enforcing bounded context isolation in master CI workflows.
2. Platform team configures Kafka topics adhering to Open Host Service schema validation.
3. Conduct quarterly strategic domain review assessing bounded context boundaries against new product initiatives.