Bounded Contexts, Shared Kernels and ACLs
Status: Public design proposal and product vision. This series presents Diem CMF .NET’s intended architecture and capabilities. Proposed features remain subject to implementation and validation; existing components are identified separately.
Pluggability requires explicit ownership. If every module can directly mutate every other module's model, a package boundary alone does not provide a useful extension contract.
The proposed context map groups responsibilities by the language and invariants they own. It does not require a separate process or database for every bounded context.
Context ownership
| Bounded context | Owns | Communicates through |
|---|---|---|
| Modeling | Type definitions, relationships, constraints and model revisions | Validated model contracts |
| Generation | Generator inputs, owned outputs and build diagnostics | Generation requests and artifact descriptions |
| Content | Editorial records, revisions and publication | Published-content views and publication operations |
| Page composition | Views, layouts, areas, zones and component bindings | Composition and renderer contracts |
| Administration | Module presentation, editor selection and operation dispatch | Module descriptors and application services |
| Lab operations | Instances, workspaces, providers and deployment state | Planning, execution and observation contracts |
| Extension catalogue | Package identity, dependencies and contributions | Resolved extension descriptions |
Application domains such as Catalogue and Enquiries retain their own business rules. Administration consumes their operations; it does not acquire ownership of those rules because it renders their forms.
Shared kernels are deliberate contracts
A small platform contract set can define extension identity, capability identity and diagnostic envelopes. More specific kernels belong to the contexts that actually share them: composition and renderers may share view descriptions; a host and its plugin share the contribution interface.
Do not put EF entities, provider implementations and every domain model into a global shared assembly. That would require unrelated contexts to change together and make every extension depend on the whole application.
A shared kernel needs named owners, a compatibility policy and a limited purpose. A higher-level kernel is appropriate only when it expresses a genuine common concept, not simply because two classes currently look similar.
Translate where meanings differ
An anticorruption layer translates an external or neighboring model into the consuming context's language. A GitLab branch or environment becomes a source of facts for a Diem version track; it is not automatically the Diem instance itself.
Likewise, an EF persistence entity need not be the shape exposed to a frontend widget. An adapter can publish a stable Product summary without exposing persistence navigation properties.
M0 through M3 describe a different axis
| Level | Example in this proposal |
|---|---|
| M3 | Primitives for defining modeling languages |
| M2 | A language describing entities, page components or Lab services |
| M1 | Acme's Product definition or one Lab's service declaration |
| M0 | A Product record, component instance or running service |
These levels describe instantiation and modeling relationships. They do not determine which team owns a bounded context or which CLR assembly contains a shared interface.
An extension can add M2 concepts and operations that interpret M1 declarations. Its runtime contribution remains subject to the same context contracts as other plugins.
Consequences for DLL composition
Plugin loading must preserve the identity of host-shared contract assemblies and resolve implementation dependencies intentionally. Two types with matching names are not necessarily the same CLR type when loaded from different assemblies or contexts. Microsoft documents this concern in its plugin tutorial (ouvre dans une nouvelle fenêtre).
The extension specification turns these boundaries into contribution and compatibility requirements.
Previous: Models, Workspaces and Release Artifacts · Next: Bundles, Binary Wrappers and Infrastructure · Series index · Section index