Application Architecture and Decomposition
Application Architecture and Decomposition tests whether you can turn a business domain into ODC apps and modules with clear boundaries, manageable coupling, and independent change. ODC groups modules into apps; modules are the main unit of design and reuse. Decompose by business capability and rate of change, then map to module types such as UI, library, and service modules.
Core rules
- Start from bounded contexts: catalog, orders, payments, identity. Each context owns its entities and rules.
- A module should have one reason to change. Splitting by technical layer alone produces a distributed monolith.
- Reuse through libraries with a deliberate public contract, not by referencing another app's internals.
- Keep cross-module calls coarse-grained. A screen should call one orchestration action, not five core actions.
- Align app boundaries with release cadence and ownership; a shared database is not an integration strategy.
Worked example
A retailer has one large app with Catalog, Orders, Payments, and Identity entities in one module. The redesign creates a Core module per bounded context, an Orchestration module for checkout, and separate End-User modules for web and mobile. Payments exposes PayOrder and owns payment state; Orders exposes PlaceOrder and does not read payment tables directly. Reasoning: checkout changes when payment providers change, while catalog changes with merchandising; separating them stops unrelated releases from colliding.
Traps
- Decomposing by team org chart so that every team must coordinate every release.
- Creating a giant Core module that becomes a new monolith.
- Letting UI modules call each other's screen actions.
- Over-decomposing into dozens of chatty modules with no independent reason to exist.