The Foundation module that points upward
A six-month-old claims application has three modules that have grown out of shape. ClaimsUI is the end-user module behind 40 screens. ClaimsCore owns the claim lifecycle logic. PolicyFoundation wraps the policy master data and is referenced by both. Last sprint PolicyFoundation was changed so that its public action PolicyValidate calls a public action in ClaimsCore to ask whether a policy has open claims. Since then Service Studio refuses to publish ClaimsUI with a circular-reference error, so developers bypass it by copying the check into ClaimsUI. That rule ('a policy with open claims cannot be closed') now lives in five places. ClaimsUI also defines its own aggregates over the Policy entity, 14 of them, all left at the default Max Records of 40, because adding a public action to PolicyFoundation 'takes too long'. Two new teams join next month and both will need policy data.
1. State the reference rules that apply and give the exact change that makes the three modules publishable again without adding another copy of the rule.
Read the worked answer
Rule set first. In the Architecture Canvas, a Foundation module may reference only Foundation or System modules. A Core module may reference Foundation and other Core modules. An End-user module may reference Core and Foundation. No module may reference an End-user module. PolicyFoundation calling into ClaimsCore is an upward reference - illegal - and because ClaimsCore already reads PolicyFoundation, it also creates the cycle the compiler reports.
Invert the call, do not copy the rule. PolicyFoundation should stay ignorant of claims. It exposes policy data only: PolicyGetById returning a PolicyInfo structure. The decision 'a policy with open claims cannot be closed' needs both claims and policies, so it belongs in ClaimsCore, which is allowed to read both. ClaimsUI then calls ClaimsCore.CanClosePolicy.
Resulting graph: ClaimsUI to ClaimsCore to PolicyFoundation. Acyclic, all references downward, and each module keeps one reason to change.
Sequencing matters. Add ClaimsCore.CanClosePolicy and repoint the screens with Find Usages before deleting PolicyValidate. A public action that still has references cannot be deleted, so the compiler enforces the safe order. Publishing PolicyFoundation first, then ClaimsCore, then ClaimsUI also matches the dependency direction, which is what lets the two teams publish independently next month.
2. How would you collapse the five rule copies and the 14 screen-level aggregates without freezing feature work?
Read the worked answer
Treat it as a facade migration. Step 1, add the single authoritative implementation (ClaimsCore.CanClosePolicy plus a read action in PolicyFoundation returning exactly the fields screens need). Step 2, repoint callers screen by screen. Step 3, delete nothing until Service Studio shows zero references.
Why a facade and not a big-bang: a signature change on a public action forces every dependent module to be republished, which would block both teams for the whole refactor. Keeping the old action as a thin wrapper that delegates to the new one means each screen can be migrated and published on its own cadence.
On the 14 aggregates: replace them with one paged read action per screen need, not one per screen. Max Records of 40 is the platform default, not a decision - it silently truncates lists and makes the count label lie, so for each aggregate decide explicitly: page size for lists, a separate aggregate using Count (Max Records 1) when a total is displayed, and index the attributes used in the filter. Also remove direct entity references from ClaimsUI to the Policy entity so that future column additions do not leak into the UI layer automatically.
Order of operations: publish PolicyFoundation additively, then ClaimsCore, then migrate ClaimsUI in batches behind an existing action name, and only then remove the duplicated rule text. No environment freeze is needed because every step is backward compatible.