Applying DDD Aggregates in a Banking ECIF

Wed, 12 Aug 2026 00:00:00 +0000

In an ECIF, the concept of “customer” is huge: retail, corporate, and interbank clients each have different attributes, relationships, and lifecycles. Forcing them into one giant Customer entity makes the code rot fast.

Slice by bounded context

Split the customer across bounded contexts:

Party (master data): unified natural-person / institution identity and base attributes.
Profile: risk appetite, marketing tags — high read/write churn.
Relationship: shareholding, guarantee, and group relationships.

Where the aggregate root goes

Each context defines its own aggregate root. In Party, Party is the root; Address and Contact are value objects, keeping cross-aggregate calls out of the consistency boundary.

ECIF in one read — why customer data must be centralized

Mon, 10 Aug 2026 00:00:00 +0000

Before ECIF, branches, internet banking, and the card center each kept their own customer records. The same person appeared with different names, IDs, and contacts across systems — making both marketing and risk control impossible.

What ECIF solves

ECIF (Enterprise Customer Information Facility) consolidates customer master data scattered across business systems into one place, exposing a single customer view.

Unique identity: a Party ID unifies natural persons / institutions, not the ID number.
Primary/secondary: supports one person many accounts, one account many cards, with unique master data.
Service-oriented: other systems query via interfaces instead of keeping their own copies.

Key technical trade-offs

Read/write split: master writes are strongly consistent; queries can hit cache / read replicas.
Auditable changes: customer changes are traced to satisfy regulatory audits.