Decomposing a Monolithic Claims Platform for ODC
A regional insurer is moving a 12-year-old claims application to OutSystems Developer Cloud. The current estate has 38 modules, 7 shared libraries, and a 'Common' module that exposes 214 public actions and 96 public entities; 26 modules reference it. Two teams cannot deploy independently because a change to Common forces a full regression. The architecture canvas shows 14 cyclic dependencies. Production releases take 45 minutes and occur weekly. The insurer wants to adopt ODC within nine months and has three squads: Claims Intake, Adjudication, and Payments. Non-functional requirements are 99.9% availability, p95 screen load under 2 seconds, and audit evidence for every status change. Each squad owns 8-14 modules, but all three depend on Common for customer, policy, and document services. The CIO has asked for a target architecture that reduces coupling without a big-bang rewrite, and for a first migration slice that proves the pattern in 10 weeks.
1. Identify the dominant architectural anti-pattern and propose a target decomposition. Explain how you would treat the Common module's 214 actions and 96 entities, including what must not be shared.
Read the worked answer
The dominant anti-pattern is a shared 'god module' acting as a de facto shared kernel for unrelated capabilities. Its 26 dependents and 14 cycles mean every change has estate-wide blast radius; the 214 actions and 96 entities are not a contract, they are an accumulation. I would decompose by business capability aligned to the three squads: Intake, Adjudication, and Payments, with a small platform layer for cross-cutting concerns.
Common should be split into (a) domain services that own Customer, Policy, and Document data, (b) technical libraries for logging, security, and UI, and (c) a deliberately small shared kernel of stable value objects. Do not expose the 96 entities as a cross-module data model; entities are schema, and public entities couple every consumer to storage. Expose task-oriented service actions with DTOs, versioned contracts, and explicit ownership.
Use a strangler sequence: put a facade in front of Common, extract the least-coupled capability first, and migrate consumers incrementally. The 10-week slice should be Claims Intake, because it has fewer transactional dependencies, and must prove independent deployment, no new cycles, and p95 under 2 seconds before scaling.
2. The CIO proposes 12 microservices, one per module group, with each service owning its own database. Evaluate this against the nine-month constraint and p95 requirement.
Read the worked answer
Twelve services for three squads and nine months is a recipe for a distributed monolith. The constraint is not just delivery time; each new database introduces integration latency, consistency handling, operational runbooks, and failure modes. With a p95 screen-load target of 2 seconds, a single screen that fans out to four or five services can easily miss the budget once retries and network hops are included. The current cycles also mean service boundaries are not yet proven; extracting 12 services would freeze guesses into contracts.
I would target three to five deployable domain services aligned to the squads, plus shared libraries, and split further only where a measured scaling or ownership need appears. Data ownership should follow transactional boundaries: Policy and Customer can be separate, but Adjudication and Payments may need a shared transactional boundary at first. Use asynchronous events for status propagation and read models for screens. Keep a modular monolith option for low-change capabilities. The decision test is independent deployability and measured p95, not service count.
3. What governance rule would you put in place to prevent the Common module from re-emerging, and how would you measure it?
Read the worked answer
Prevent recurrence with an enforceable dependency rule, not a document. Rule: a module may depend only on modules in its own bounded context or on the platform layer; no module may be referenced by more than three bounded contexts without an approved contract. Public elements require an owner, version, and consumer list. The architecture canvas must show zero cycles, and CI should fail a merge that adds a cycle or an unapproved public entity. Set a fan-in budget for shared libraries (for example, no more than five consumers for domain libraries) and track fan-out per screen.
Measure leading indicators monthly: number of cycles, number of modules changed per release, percentage of releases that require coordinated deployment, and p95 regression after change. Also track contract churn for shared actions. If a shared module's change frequency exceeds its consumers' release cadence, it is becoming a god module again. Governance should include a lightweight architecture review for new public contracts, with a 48-hour SLA so it does not become a bottleneck.