The Core module that everything references
Northwind Retail runs its order management on OutSystems O11 with six product teams. All business logic lives in a single module, Core, which exposes 118 entities and 74 public server actions. Forty-seven consumer modules reference Core directly, including screens in the End-User layer and integrations in the Foundation layer. A recent change adding a single attribute to the Customer entity triggered a deployment plan of 39 applications and a 3-hour production deploy. The team also reports circular references between Core and a Billing module, which they resolve by copying entity definitions. The architecture team wants a target design before the next release cycle, and the CIO has frozen new features for two sprints to allow refactoring. There are 11 shared reference tables used by all teams and 6 transactional entities owned by different bounded contexts.
1. Identify the architecture design violations in this setup and explain their consequences for change impact and deployment.
Read the worked answer
Violations
- Layer inversion and bidirectional coupling. Foundation modules should not reference Core, and Core should not reference End-User modules. Dependencies must point one way, from UI toward foundation.
- God module. Core mixes reference data, canonical entities, and transactional logic. Every consumer depends on the whole module, so any change inherits the blast radius of the largest module.
- Exposed entities used as a contract. 118 exposed entities let consumers bind directly to the physical schema. Adding one attribute changes the public surface and forces recompilation and redeployment of consumers.
- Circular dependency resolved by duplication. Copying entity definitions creates two sources of truth; data diverges and reconciliation becomes a manual integration project.
Consequences The 39-application deployment plan is the direct output of the dependency graph, not a tooling accident. A 3-hour deploy is a symptom of fan-in. Impact analysis cannot isolate a change, so testing scope expands to all consumers and the team loses the ability to reason about risk. The copied entities make the architecture appear decoupled while increasing the real cost of every future change.
2. Propose a target architecture canvas for Northwind and describe how to migrate to it incrementally without a big-bang rewrite.
Read the worked answer
Target canvas
- Foundation: the 11 shared reference tables in one Foundation_Reference module, read-only exposed entities, owned by the platform team.
- Canonical: Customer, Product, and shared contracts in Canonical_CRM and Canonical_Catalog. Public actions and read-only entities only; no process logic.
- Transactions: Orders and Billing as separate modules, each owning its transactional entities and exposing service actions.
- End-User: screens and UI flows only; consume canonical read-only entities or service actions, never another context's entities.
- Orchestration: a thin process module that composes across contexts through public service actions or BPT.
Migration in slices
- Use dependency analysis to inventory every consumer of Core.
- Create canonical modules with compatibility wrappers that delegate to Core.
- Move one bounded context at a time, starting with reference data because it is read-only and low-risk.
- Update consumers to the new public actions or read-only entities.
- Remove wrappers and copied entities.
- Enforce the canvas in review. Track deployment plan size per change as the migration KPI; it should fall release by release.
3. How would you permanently break the circular dependency between Core and Billing?
Read the worked answer
Identify the shared contract behind the cycle, most likely Customer or an invoice status. Move it to the canonical layer. Billing then depends on Canonical, and Core depends on Billing through a public service action or an event, never a back-reference to Billing entities. If both contexts genuinely must react to each other, introduce a thin orchestrator module that references both and owns the workflow in BPT; keep the data modules acyclic.
The durable rule is directional: transaction modules may reference canonical and foundation; no transaction module references another transaction module's entities; cross-context reads go through service actions or read-only views. Enforce it with a pull-request gate that runs dependency analysis and rejects cycles, foundation-to-end-user references, and duplicated entity definitions. Without the automated check, the cycle will reappear the first time a deadline pressures the team. The fix is structural, not a one-off cleanup.