Case Study on Domain Decomposition and Business Led Cloud Migration

Summary

Large modernization programs need a way to make progress before the entire system is ready to move. Business stakeholders also need enough information to judge whether the next increment is worth pursuing, what risks remain, and where priorities should change.

A financial industry project addresses this challenge through business-aligned decomposition. The program is moving the backend-for-frontend (BFF) layer supporting online banking from on-premises infrastructure to AWS. Its strategy uses Domain-Driven Design (DDD): business journeys inform domain boundaries, logic and data are largely independent within each domain, and domains communicate through an event-driven approach.

The delivery opportunity is to turn those boundaries into smaller increments that can be understood, validated, and reviewed. The useful unit of progress is a bounded business capability with evidence behind it.

Business journey → domain boundary → end-to-end delivery slice → no-regret investment → validation evidence → business decision → execution

This case study explains that connection. It builds on the existing SDLC article’s small-step delivery and evidence-based validation principles, while shifting the emphasis from how engineering work is performed to how a large program is divided and how business stays informed.

The approach

The confirmed scope is the online banking BFF layer. It should not be described as a migration of the entire core banking platform.

A business journey provides a starting point for understanding what a customer is trying to accomplish and which responsibilities support that outcome. In BOSMOD, this perspective informs the domain decomposition. Keeping most logic and data within clear domain boundaries creates a basis for work to progress with fewer cross-domain dependencies.

The boundaries are not completely independent. A journey may cross domains, and a domain may support several journeys. Event-driven communication still requires agreement on business meaning, ownership, and the behavior expected from producers and consumers.

The intended delivery advantage is that a team can work on a bounded part of the modernization, expose its dependencies, and validate its behavior without treating the whole program as one indivisible release. That advantage must be demonstrated through actual delivery evidence rather than assumed from the architecture alone.

How to break a large program into smaller domains

Start with the banking outcomes the platform supports. A large migration becomes easier to plan when its scope can be discussed as account servicing, money movement, lending, customer engagement, and supporting capabilities. These groupings help organize discovery; the domain boundaries beneath them need to be tested against business rules, data ownership, and dependencies.

A useful distinction is between a journey, which describes an outcome across steps; a domain, which owns a coherent business responsibility; and a delivery slice, which implements a limited part of that responsibility. A screen or menu item is a useful discovery input, but does not automatically define a bounded context, a microservice, or an independently releasable unit.

Work from journeys to responsibilities

1. Inventory the journeys. List what customers and colleagues need to accomplish, including the normal path, exceptions, and support activities. For each journey, record the outcome and the business owner who can validate it.
2. Map the capabilities behind each journey. Identify decisions, rules, data, events, and existing system interactions. Group responsibilities that share business meaning and tend to change together.
3. Propose domain boundaries. Give each candidate a clear purpose, owned rules and state, inputs and outputs, and explicit exclusions. Identify which data it owns and which it only reads from another system. In a BFF migration, this does not imply moving ownership of core banking records into the BFF.
4. Test the boundaries with business and engineering. Ask whether the candidate has a coherent vocabulary and owner, whether important consistency requirements can be met, and whether changes can be validated with limited coordination. Frequent joint changes or tightly coupled state may indicate that a boundary needs to move.
5. Sequence migration by value, risk, and dependency. Compare the business importance of each candidate, complexity of its dependencies, readiness of its rules, and cost of transition. Select an early slice that produces useful evidence without requiring the entire platform to move first.
6. Turn the selected domain into small delivery slices. Agree on one outcome, its acceptance criteria, and the evidence needed for the next decision. Use what the slice reveals to refine both the domain boundary and the next increment.

Figure 1. A decomposition method for this migration approach. The review loop allows boundaries and sequencing to improve as evidence becomes available.

flowchart TD
A["Large online banking migration"] --> B["Inventory business journeys"]
B --> C["Map capabilities, rules and data"]
C --> D["Propose domain boundaries"]
D --> E["Test ownership, consistency and dependencies"]
E --> F["Sequence by value, risk and readiness"]
F --> G["Choose an end-to-end delivery slice"]
G --> H["Validate behavior and business outcome"]
H --> I["Business decides the next increment"]
I --> G
H -. "Refine a boundary when needed" .-> D

Build a banking domain map

The following map uses the banking examples identified for this discussion. It is a candidate capability and domain landscape, not a confirmed service topology or deployment plan. The headings group the scope for discovery; they do not require all capabilities in a group to share one implementation.

Figure 2. Candidate banking domains organized for discovery.

flowchart LR
A["Online banking modernization scope"]
A --> B["Accounts and servicing"]
A --> C["Money movement"]
A --> D["Products and engagement"]
A --> E["Customer and supporting capabilities"]
B --> B1["Account Summary"]
B --> B2["Account Details"]
B --> B3["Deposit Management"]
B --> B4["Taxes and Documents"]
C --> C1["Transfer"]
C --> C2["Global Transfer"]
C --> C3["EMT"]
C --> C4["Bill Pay"]
D --> D1["Card Control"]
D --> D2["Unsecured Lending"]
D --> D3["Loyalty"]
D --> D4["Offers"]
E --> E1["Customer Profile"]
E --> E2["Customer Support"]
E --> E3["Alerts"]
E --> E4["IAM"]

Several boundary questions matter before this becomes a delivery plan:

• Account Summary and Account Details: Do these represent separate business responsibilities, or different views over the same account model? Separate screens alone do not justify separate ownership of account data.
• Transfer, Global Transfer, EMT, and Bill Pay: Where do eligibility, recipient handling, limits, execution, and exception handling differ? Keep distinct business rules visible, while identifying shared services and underlying payment systems.
• IAM and Alerts: Treat identity, access, and notification needs as explicit cross-domain dependencies. Reuse their capabilities through agreed contracts rather than reproducing their logic in every domain.
• Customer Profile, Offers, and Loyalty: Clarify the authoritative source for customer information and which domain owns each decision. Shared use of customer data does not mean every domain should own or directly modify it.

For each candidate, produce a short domain boundary card: business purpose, accountable owner, included and excluded responsibilities, owned rules and data, external dependencies, contracts and events, and a first testable slice. This gives business and delivery teams something concrete to review before committing to a larger build.

Use a boundary to define the first increment

Consider a proposed Transfer slice for one agreed transfer scenario. Its scope could include validating the request against the applicable rules, invoking the existing execution capability, tracking the outcome, and exposing the result through the BFF. Other transfer types remain outside that slice until deliberately selected.

The Transfer domain would own the transfer-specific behavior assigned to it; identity checks and customer notifications would use defined supporting capabilities. Each event needs a clear meaning: “request accepted” and “transfer completed” represent different business states.

Figure 3. Illustrative interaction for a Transfer slice. This shows how domain responsibilities can stay separate while a journey remains end to end. The names and interactions below are examples to validate, not a record of the implemented project architecture.

sequenceDiagram
participant Channel as Online banking channel
participant Transfer as Transfer domain
participant IAM as IAM capability
participant Execution as Existing execution system
participant Events as Event delivery
participant Alerts as Alerts capability
Channel->>Transfer: Submit agreed transfer scenario
Transfer->>IAM: Verify required identity and access context
IAM-->>Transfer: Access decision
Note over Transfer: Continue only when access and domain rules pass
Transfer->>Execution: Request execution through agreed contract
Execution-->>Transfer: Report execution outcome
Transfer->>Transfer: Record the confirmed business state
Transfer-->>Channel: Return appropriate status
Transfer-)Events: Publish event for confirmed state
Events-)Alerts: Deliver event
Alerts->>Alerts: Apply notification rules

The implementation must define failure handling and reliable event publication, including retries and duplicate processing. Completion is reported only when the execution outcome supports it. The diagram deliberately leaves transport and AWS service choices open.

A first increment should leave useful work behind even if later sequencing changes: validated rules, explicit contracts, tested behavior, or a reusable transition path. This makes the no-regret investment visible to business. The review can then address a specific decision: extend the proven scenario, resolve a dependency, change a boundary, or prioritize a different domain.

Turning domains into iterative delivery

The following operating model is recommended for making that architectural strategy useful to both delivery teams and business stakeholders. It is not a retrospective claim that every practice has already been implemented in the project.

Define a small business outcome

A domain may still be too large for a single useful increment. Split it further into a narrow, end-to-end slice with an explicit outcome, supported scenarios, and acceptance criteria.

“Finish the database,” “rewrite the APIs,” and “configure AWS” are engineering activities. A business-facing increment should explain which behavior can be demonstrated when those activities come together.

For example, if a transfer journey were selected, an initial slice could cover one agreed transfer scenario, its relevant eligibility rules, the required downstream interaction, and a defined failure response. Additional variants would remain visible as later scope.

End-to-end means enough connected behavior to validate that selected journey through the BFF migration scope. It does not require replacing the underlying core banking systems.

Make independence and dependencies visible

Each slice should state what it owns, which data it depends on, and where it interacts with another domain or an existing system. Shared dependencies must remain visible in the delivery plan rather than being hidden inside a claim of domain independence.

For event-driven interactions, agree on the event’s meaning, its owner, and what the consumer can rely on. Validate relevant failure cases such as delayed or duplicate events. Do not assume that every interaction must be asynchronous merely because the architecture is event-driven.

This gives the team a practical way to distinguish work it can progress independently from work that requires coordinated integration or a business decision.

Validate behavior before expanding scope

Each slice should produce a compact evidence package linking the agreed behavior to its rules, implementation, test results, and unresolved questions.

Business-rule discovery may require more than reading source code. The existing Transfers case describes rules held in external configuration and the need for SME validation. That observation is useful when defining a slice: a technically correct implementation can still be incomplete if its business rules have not been understood.

A slice review should therefore establish what has been verified, what is assumed, and what remains outside the current scope. The next increment can then build on an accepted understanding rather than carrying ambiguity forward.

Give business information it can act on

Business visibility should follow the same decomposition as delivery. A program-level percentage complete cannot explain whether a particular customer capability is ready, which uncertainty has been removed, or what decision is needed next.

For each increment, present a short review covering the following:

1. What capability has progressed?
   Evidence to show: Defined journey, included scenarios, demonstration and acceptance results
   Decision enabled: Accept the outcome or refine the scope
2. What have we learned?
   Evidence to show: Verified rules, assumptions resolved and remaining exceptions
   Decision enabled: Resolve uncertainty before expanding
3. What still depends on others?
   Evidence to show: Domain interactions, shared dependencies and integration results
   Decision enabled: Address a dependency or resequence work
4. How ready is it for use?
   Evidence to show: Operational checks, transition criteria and recovery approach
   Decision enabled: Approve the appropriate next transition step
5. What should we invest in next?
   Evidence to show: Remaining scope, current risks and estimates revised using evidence
   Decision enabled: Continue, reprioritize, defer or stop

The purpose is to make the next commitment specific. A business review might support extending a proven scenario, prioritizing a more valuable journey, or resolving a dependency before additional development. It should also allow the business to defer work where the evidence does not yet justify further investment.

Rapid iteration comes from shortening the distance between a delivery increment and a decision. It does not require every increment to produce a new customer feature or an immediate production cutover.

Keep deployment and business adoption separate

A migration has several meaningful stages:

• Deployment: The new implementation is available in the target environment.
• Traffic switching: An agreed portion of activity moves to the new path after the required validation and operational readiness.
• Retirement: The old path is removed after its remaining dependencies and transition obligations have been addressed.

These stages may occur at different times. Reporting them separately makes coexistence, support needs, and remaining work visible. A successful deployment alone does not establish that traffic has switched or that the migration is complete.

For each slice, the delivery plan should identify the evidence and accountable decision needed to move between stages. The exact transition mechanism should follow the system’s constraints, rather than being prescribed generically.

What this approach changes

The business can review progress in terms of capabilities and evidence, while engineering retains a clear view of the technical work and dependencies beneath them.

A completed slice also provides information for the next one. It can reveal missing rules, an unsuitable domain boundary, a shared dependency, or a different sequencing opportunity. The plan can change while the program continues, without waiting for a single end-of-project assessment.

The central lesson is that project decomposition must support both execution and decision-making. DDD supplies useful boundaries; small delivery slices and clear validation evidence make those boundaries actionable.

Evidence to add before external use

This is an approach-led draft, not a quantified success story. To strengthen it, add one actual BOSMOD slice and the evidence showing:

• The business journey and why that boundary was chosen.
• What was included and excluded from the increment.
• What was validated and its actual deployment or traffic-switching stage.
• What the business decided after reviewing the results.
• Any measured change in delivery time, rework, quality, or operating cost, with a baseline and source.

No measured improvements or completed-migration outcomes are asserted here. Confirm which project details may be shared externally before sending.