Framework · Architecture
The house, the hallway and the doorbell.
Most systems can operate effectively with three simple structural elements — a modular monolith, an orchestrator, and outcome-based events. Simple architectures scale further than most teams expect.
The complexity trap
Teams start talking about microservices, event-driven systems, message brokers, workflow engines and distributed orchestration — before the first real business problem is even solved.
Systems become complex before they become valuable. Most organisations do not need complex distributed systems. They need clear structure.
Three structural elements
The core application: clearly separated business modules — orders, payments, inventory, customers, notifications — each a room in the house.
Characteristics: Clear module boundaries · Shared runtime environment · Internal communication through direct calls · Consistent data model
The problem is rarely the monolith. The problem is lack of modularity inside it.
Manages workflows across modules. Instead of modules calling each other directly, the orchestrator controls the process: User → Orchestrator → Modules.
Benefits: Clear workflow visibility · Reduced module coupling · Easier debugging · Predictable execution flow
Inside a house, rooms do not connect randomly. Movement happens through hallways.
Events ring when something important happens — business milestones other systems can react to.
Good events: OrderCompleted · PaymentFailed · AccountCreated · ShipmentDispatched
Events should signal important outcomes, not internal workflow steps.
When architecture should evolve
At that stage, parts of the monolith may evolve into services. But the transition should happen when complexity demands it, not when architecture trends suggest it.
Interactive
List your modules, the workflows that cross them and the events you publish. The check finds unowned rooms, missing hallways and doorbells that ring for the wrong things — and tells you whether any part has outgrown the model.
1 · The house: modules
Your business modules — the rooms. Who owns each?
2 · The hallway: workflows
Business processes that cross modules. Who controls the flow?
3 · The doorbell: events
Events your system publishes. Is each a business milestone, or a step inside a workflow?
What the model says
Add your modules, workflows and events to check them against the model.
Implementation · 30–60 days
Identify core business modules — orders, payments, inventory, customers.
Success metricEach module has clear ownership and responsibility
Centralise process flows. Avoid uncontrolled module-to-module calls.
Success metricBusiness workflows are visible and traceable
Define when events are allowed. Events should represent business outcomes.
Success metricEvents represent meaningful system signals
Go deeper
Debating microservices?
Bring the check you made above to a free 30-minute diagnostic.