The Domain Determines the Architecture. Leadership Determines the Accountability.
What the architecture diagram does not show, and why it is the most important thing about your technology estate.
How many architectural models is your organisation running simultaneously.
And how many accountability models have been explicitly designed to match them.
If the second number is smaller than the first, that gap is not an oversight. It is the governance risk the architecture diagram will never show.
The Perception Problem.
Two contradictory perceptions govern most architectural conversations in financial services.
The first. The monolith is legacy. Every mature organisation should be moving toward microservices and distributed architecture. The future is decentralised.
The second. Distributed systems are too complex. The monolith was simpler and the move away from it was a mistake.
Both perceptions are wrong in the general case. Both produce expensive decisions.
The perception precedes the analysis in both cases. The architecture is chosen before the domain is understood. The accountability model is designed, if it is designed at all, after both.
Domain Driven Design as the Governing Framework.
The intellectual framework that makes the right architectural choice possible is Domain Driven Design. Not as a methodology for distributed systems specifically. As a way of thinking about domain boundaries that applies equally to modular monoliths, distributed services, and hybrid estates.
Eric Evans introduced the bounded context as the unit of domain analysis. Within a bounded context the language is precise, the ownership is clear, and the rules of the domain govern every decision. Across the boundary an explicit contract governs the interaction.
The critical insight for the architectural conversation is this. Bounded contexts apply to both models.
In a well-designed modular monolith, bounded contexts are module boundaries. The domain logic is separated. The coupling is managed through internal interfaces. The context is independently modifiable within the monolith even though it is not independently deployable.
In a distributed system, bounded contexts are service boundaries. The domain logic is independently deployed. The coupling is managed through external contracts. The context is independently modifiable and independently deployable.
The shift from modular monolith to distributed is not a shift in domain thinking. It is a decision to make the bounded context independently deployable rather than independently modular. That distinction determines which model serves the domain rather than which model the organisation prefers.
This means the modular monolith deserves recognition as a legitimate architectural destination in its own right. Not a stepping stone to microservices. For many organisations and many domains it is the right answer.
When the Modular Monolith Is Right.
The modular monolith is right when the domain characteristics favour strong consistency, stable boundaries, and contained complexity.
The general ledger is the canonical financial services example. A ledger entry that must update multiple accounts atomically, maintaining double-entry integrity across a complete set of books, requires strong transactional consistency. Distributing that capability introduces complexity that is expensive to manage and risky to get wrong. The consistency requirement is not a technical preference. It is a regulatory and commercial obligation. The domain characteristic governs the architectural choice.
The modular monolith is also right when domain boundaries are not yet well understood. Distributing a domain whose boundaries are still being discovered produces services that will need to be redesigned as understanding develops. The cost of reorganising incorrectly drawn service boundaries is significantly higher than reorganising module boundaries within a modular monolith.
The honest trade-off. The modular monolith’s strength is consistency and simplicity at the boundary. Its hidden cost is the complexity that accumulates internally when bounded context discipline is not maintained. The coupling grows. The regression surface expands. The cost arrives when the organisation needs to change at a rate the internal complexity cannot support.
When Distribution Is Right.
Distribution is right when the domain characteristics favour independent evolvability, differential scalability, and clear bounded context ownership.
Payment instruction initiation illustrates this well. The capability that initiates a payment instruction has different scalability requirements, different release cadence needs, and different ownership characteristics from the capability that settles it. These are distinct bounded contexts with different consistency requirements and different rates of change. Distributing them enables each to evolve at its own pace without the coordination overhead a shared deployment boundary would impose.
The honest trade-off. Distribution’s strength is independent evolvability and fault isolation. Its cost is operational complexity, observability requirements, and the accountability discipline required to maintain genuine independence across service boundaries. The coordination a modular monolith handles internally through shared transactions must be handled externally through contracts, messaging, and distributed consistency mechanisms.
A distributed system without explicit ownership at every service boundary has not achieved the independence it was designed for. It has achieved technical decentralisation while remaining organisationally coupled. Responsibility does not follow the architecture. It must be designed alongside it.
The Financial Services Hybrid Reality.
Understanding the hybrid requires capability-level analysis rather than domain-area-level labels.
Most financial services organisations are running a hybrid estate. Not by design. By history, regulatory constraint, and strategic evolution. And the hybrid is not simply modular monolith here and microservices there. It is a collection of capabilities each with its own domain characteristics, each requiring the model that best serves its consistency requirements, scalability needs, and ownership characteristics.
The general ledger may suit modular monolith characteristics. Product configuration management may have different evolvability needs that suit distributed characteristics. Payment instruction initiation may have different characteristics again. These are not all the same model because they sit within the same broad domain area. They are distinct capabilities that should be evaluated individually before an architectural model is assigned.
What is often called the digital channel adds a further nuance. A mobile banking application or internet banking platform is not a domain in its own right from a DDD perspective. It is a presentation and orchestration layer that consumes domain services. Its architectural characteristics are driven by its role as a consumer and orchestrator rather than by domain ownership. Treating it as a domain produces bounded context boundaries determined by channel rather than by business capability.
DBS Bank’s transformation, recognised by Harvard Business Review as one of the top ten strategic transformations of the decade, offers one of the most instructive publicly documented examples of accountability designed alongside architecture at scale. Rather than assuming accountability would follow architectural decisions, DBS created 33 platforms each aligned to a business segment or product domain, and each jointly led by a business leader and a technology leader through a two-in-a-box model. A structured approach to classifying capabilities as decommission, invest, or retain preceded the architectural decisions. The accountability model was not an afterthought to the architectural model. It was designed with the same deliberateness.
The Three Accountability Models a Hybrid Requires.
Most organisations design one accountability model for their entire estate. A hybrid estate needs three simultaneously.
Modular monolith accountability requires clear ownership of the whole, clear governance of the internal change process, and active maintenance of the bounded context discipline within the modular monolith. Without this discipline the modular monolith degrades into an unstructured one and the hidden complexity cost accelerates.
But explicit modular monolith accountability alone is insufficient in a hybrid estate.
Distributed accountability requires clear ownership of each service boundary aligned to a bounded context and explicit governance of inter-service contracts. The ownership must be assigned before the service is deployed. Not discovered during the first incident that crosses its boundary.
But explicit distributed accountability alone leaves the most consequential surface unaddressed.
Boundary accountability is the most frequently absent. It is the ownership of the API contracts, the consistency guarantees, and the failure behaviour at the points where the modular monolith and the distributed services meet. This accountability surface is created by the hybrid itself. It requires explicit design and explicit ownership. Without it the hybrid estate has two accountability models and one accountability gap. The gap is where the most consequential failures will find their home.
In one programme I was directly involved in, the loyalty domain owned value calculation based on transaction behaviour rather than passing responsibility downstream through flags. The boundary was drawn with accountability in mind from the outset. The domain owned its outcome. When something went wrong there was no ambiguity about who was responsible for understanding and resolving it. The ownership clarity produced the response clarity. The blast radius of every failure within that domain was contained because the accountability was explicit before the incident rather than negotiated during it.
That clarity does not emerge from the architecture diagram. It is a leadership decision made before the diagram is drawn.
The Leadership Decision.
The accountability model is not a technical design decision. It is a leadership decision about how responsibility is structured across the organisation.
Technology can enable distributed accountability. Only leadership can require it.
The organisations that navigate hybrid estates well are not the ones with the most sophisticated architecture. They are the ones where the domain thinking preceded the architectural decision, where the architectural decision preceded the accountability design, and where leadership treated all three as governance responsibilities rather than technical ones.
The domain model and the accountability model are the two most important signals about a technology estate that the architecture diagram does not show. An estate with clear bounded context thinking and explicit accountability at every boundary is a fundamentally different proposition from one with technically sophisticated services and implicit ownership. The difference is not visible in the diagram. It is visible in the governance conversation and in the incident response.
The architecture diagram shows what was built.
It does not show whether anyone is responsible for it.
The Sutra
A system can be distributed by design. Accountability never distributes itself.