📘 Chapter 4:

Event-Driven Microservices and Domain-Driven Design

1. Why Microservices Alone Failed

Many banks began modernization by adopting microservices.

They:

• Broke monoliths into smaller services

• Exposed APIs

• Deployed applications on containers

Yet, the outcome was often disappointing.

Distributed systems… with monolithic behavior

❗ What Went Wrong?

• Services aligned to technical layers instead of business domains

• Heavy synchronous (API-to-API) communication

• Shared databases across services

• Tight coupling hidden behind APIs

💥 Result

Service A → Service B → Service C → Service D

│ │ │ │

└──────── Cascading dependencies ───┘

A single failure propagates across the entire chain.

2. The Shift to Domain-Driven Design (DDD)

To address these issues, architecture must shift from a system-centric to a business-centric perspective.

🔷 What is DDD?

Domain-Driven Design (DDD) is about:

👉 Designing systems around business domains and capabilities

—not around:

• ❌ User interfaces

• ❌ Databases

• ❌ Technology layers

3. Understanding Domains in BFSI

Let’s look at how this applies in a banking context.

❌ Traditional System-Centric View

• LOS (Loan Origination System)

• CBS (Core Banking System)

• AML system

✅ Domain-Centric View

Lending Domain

• Application processing

• Credit decisioning

• Disbursement

Customer Domain

• Profile management

• KYC and identity

Risk and Fraud Domain

• Fraud detection

• Risk scoring

Compliance Domain

• AML monitoring

• Regulatory reporting

Domains define boundaries. Systems implement them.

4. Bounded Context: The Most Critical Concept

Each domain must operate within a clearly defined boundary.

A bounded context owns:

• Its own data

• Its own business logic

• Its own lifecycle

🔷 Bounded Context Model

┌──────────────────────┐

│ Lending Context │

│ (Own DB, Logic) │

└──────────┬───────────┘

▼

┌──────────────────────┐

│ Risk Context │

│ (Own DB, Logic) │

└──────────┬───────────┘

▼

┌──────────────────────┐

│ Compliance Context │

│ (Own DB, Logic) │

└──────────────────────┘

No shared databases. No hidden coupling.

5. Event-Driven Architecture: The Missing Piece

Even with DDD, systems can still become tightly coupled if they rely heavily on synchronous APIs.

🔥 The Solution: Event-Driven Architecture (EDA)

🔷 Event-Driven Flow

Loan Application Submitted

│

▼

Event: ApplicationCreated

│

┌──────────┼──────────┬──────────┐

▼ ▼ ▼ ▼

KYC Fraud Credit Notification

Service Service Service Service

Key Idea:

• Services publish events

• Other services react independently

No direct dependency. No waiting.

6. Event vs API: When to Use What

Scenario	Approach
Immediate response required	API
Asynchronous processing	Event
Cross-domain communication	Event
User interaction	API

Modern architectures combine APIs and events strategically.

7. Event Design in BFSI

Events must be:

• Business meaningful

• Immutable

• Versioned

🔷 Example Events

• CustomerOnboarded

• KYCCompleted

• FraudCheckCompleted

• LoanApproved

• PaymentProcessed

Events describe what happened, not what should be done.

8. End-to-End Lending Flow (Event-Driven)

🔷 Real Enterprise Flow

Customer Applies for Loan

│

▼

API Gateway → Lending Service

│

▼

Event: ApplicationCreated

│

┌──────────┼──────────────┬──────────────┐

▼ ▼ ▼ ▼

KYC Fraud Credit Document

Service Service Service Service

│ │

▼ ▼

Event: FraudScore Event: CreditScore

│ │

└──────┬───────┘

▼

Decision Service

│

▼

Event: LoanApproved

│

▼

Disbursement Service

This model enables parallel processing and real-time decisioning.

9. Orchestration vs Choreography

🔷 Choreography (Event-Driven)

• Services react to events independently

• No central controller

✔ Highly scalable❗ Difficult to trace end-to-end flow

🔷 Orchestration

• Central workflow engine controls execution

✔ Better visibility and control❗ Can become a bottleneck

🔷 Best Practice: Hybrid Approach

Event-Driven Services + Workflow Orchestrator

(Decoupled) (Control Layer)

Use orchestration for complex workflows and events for scalability.

10. Data Management in Microservices

❗ Golden Rule:

Each service owns its data

🔷 Key Patterns

• Database per service

• Event sourcing (optional)

• CQRS (Command Query Responsibility Segregation)

🔷 Data Flow

Service A → Event → Service B → Updates its own database

No direct database access across services.

11. Reliability and Resilience Patterns

In BFSI systems, failure is not an option.

Key patterns:

• Idempotency

• Retry with exponential backoff

• Circuit breakers

• Dead-letter queues

• Outbox pattern

These ensure reliable, consistent event processing.

12. Observability in Event-Driven Systems

Event-driven systems introduce new operational challenges.

🔷 Challenges:

• No single execution flow

• Asynchronous processing

• Multiple distributed services

🔷 Solutions:

• Correlation IDs

• Distributed tracing

• Centralized logging

13. Anti-Patterns to Avoid

• ❌ Distributed Monolith

  
  

  Tight coupling via APIs

• ❌ Shared Database

  
  

  Hidden dependencies

• ❌ Chatty Services

  
  

  Excessive synchronous calls

• ❌ Overloaded Events

  
  

  Large, complex payloads

14. What This Enables

Combining DDD with event-driven architecture enables:

• Real-time processing

• Independent service scaling

• Faster release cycles

• Strong fault isolation

15. Final Thought

Microservices provide structure.Domain-Driven Design provides meaning.Event-driven architecture provides freedom.

Together, they enable a scalable, resilient, real-time banking platform.