Domain-Driven Design in Banking

Banks aren’t just financial institutions – they’re tangled ecosystems of regulations, legacy systems, and rapidly evolving customer expectations. Traditional IT approaches often crumble under this complexity. Domain-Driven Design (DDD) offers a path forward by aligning technology with business reality. But where do you start? Here’s how to take the first steps without boiling the ocean.

• Tame Complexity: Regulations (AML, KYC), multi-channel banking, and legacy core systems create inherent complexity. DDD provides tools to decompose it.
• Break Silos: DDD forces collaboration between business experts (risk officers, loan advisors) and tech teams.
• Modernize Incrementally: DDD lets you carve out modern services around legacy cores (e.g., payments, onboarding).

Avoid core banking or regulatory reporting first! Target domains where:

• Complexity is high, but risk is contained: e.g., Customer Onboarding, Loan Origination, or Wealth Management Advisory.
• Business experts are engaged: Passionate product owners = success fuel.
• Outcomes are measurable: e.g., "Reduce onboarding time from 10 days to 2."

• Goal: Build a shared language (Ubiquitous Language).
• How:
  • Gather real domain experts (not just managers): e.g., a seasoned loan underwriter + compliance officer + tech lead.
  • Map key processes (Event Storming): Use sticky notes on a wall (physical or virtual). Focus on:
    • Domain Events: e.g., Customer Identity Verified, Credit Risk Assessed, Loan Application Rejected.
    • Commands: e.g., Verify Customer Address, Calculate Debt-to-Income Ratio.
  • Banking Tip: Start with a happy path (e.g., "Simple Retail Loan"), then add exceptions (e.g., "Cross-Border KYC Hold").

• What it is: A logical boundary where a specific domain model applies (e.g., Customer Onboarding ≠ Fraud Detection).
• How to start:
  • From your workshop, identify a cohesive subdomain (e.g., Identity Verification within Onboarding).
  • Draft explicit context boundaries: "Inside this BC, 'Customer' means verified identity data. Outside, it may mean marketing preferences."
• Banking Reality: Your BC will likely need to integrate with a legacy system (e.g., mainframe KYC check). Plan adapters early.

• What: A transactional boundary protecting business rules (e.g., LoanApplication aggregate enforcing "draft vs. submitted" rules).
• Start small:
  • Pick 1-2 critical aggregates per BC (e.g., in Payments: PaymentOrder + AccountBalance).
  • Banking Critical: Enforce invariants like "Payment must reserve funds atomically" or "AML check must precede execution."

• Problem: BCs will communicate (e.g., Onboarding → Core Banking).
• Start simple:
  • Anti-Corruption Layer (ACL): Protect your new BC from legacy chaos. Wrap that mainframe API!
  • Publish Domain Events: e.g., OnboardingCompleted → triggers CreateCoreBankingCustomer in another system.
• Avoid: Distributed transactions across BCs (banking's poison pill).

• Ignoring Regulatory Constraints: Model regulations explicitly (e.g., an AMLComplianceRule object).
• Over-Engineering: Don’t model the entire bank. Start with one BC and iterate.
• Underestimating Legacy Integration: Plan for data synchronization early.
• Tech-Driven DDD: DDD is about business alignment. If business experts aren’t in the room, stop.

1. Fix a Pain Point: Use DDD to streamline a broken process (e.g., reducing onboarding steps).
2. Visualize Your Domain: Share Event Storming maps with leadership – it builds buy-in.
3. Measure: Track cycle time pre/post for your pilot domain.

DDD in banking isn’t about overnight transformation. It’s about strategic incrementalism: carving out domains where complexity hurts most and aligning tech with business reality. Start small, engage your experts, and let the domain lead. Your legacy systems won’t vanish, but DDD lets you build islands of clarity in the chaos.

Next Step: Run a 2-hour Event Storming session on one painful banking process. The map alone will reveal more than any document.