Environments, Instances and Diem Domains
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.
The word “environment” often covers several unrelated concepts. Diem needs explicit names because a development branch may run on production infrastructure, and a public hostname may expose only one path of one application.
This glossary is the canonical vocabulary for the series.
Hosting and application identity
| Term | Proposed meaning |
|---|---|
| Hosting environment | Resource and operational boundary where workloads can run |
| Site | Logical application or product, independent of any one deployment |
| Instance | Running application configuration with an assigned data scope and active release |
| Version track | Mutable line of development or delivery, such as main, dev or an experimental branch |
| Revision | Identified state of source definitions and code |
| Release | Recorded set of application artifacts, dependencies and compatibility information |
| Data scope | Content and business-data stores assigned to an instance |
| Runtime environment setting | Application setting such as ASPNETCORE_ENVIRONMENT, independent of hosting location |
A new release updates an instance. It does not automatically create a new empty database. A new branch instance normally receives a separate data scope under its initialization policy.
Addresses and models
A diem_domain, represented as DiemDomain in illustrative C#, is an address binding: hostname, path prefix, target instance, exposed role and applicable capabilities or policy.
It is distinct from a business domain, which is the subject modeled by the application, and a bounded context, which owns a particular model and language. A DNS record is infrastructure used to make a hostname reachable; it does not encode every Diem binding decision.
The same hostname can host separate path prefixes when routing policy permits it. Bindings must reject ambiguous ownership rather than allowing whichever plugin registers last to win.
Source and execution
| Term | Proposed meaning |
|---|---|
| Source selection | Git repository/ref, filesystem snapshot or compiled artifact set |
| Workspace | Editable files and associated tooling for one development context |
| Git checkout | A workspace whose base revision and changes can be related to Git |
| Live preview | Running output of the workspace, potentially containing uncommitted changes |
| Observed state | Measured processes, active releases, routes and service health |
| Desired state | Versioned configuration the Lab is asked to realize |
A branch name selects a moving reference. A commit identifies a source state. A workspace may contain changes beyond that commit. A release records the actual inputs used to build it.
Examples
| Binding | Hosting | Target | Purpose |
|---|---|---|---|
www.monsite.com/ |
Production | Main instance and its active release | Public frontend |
admin.monsite.com/ |
Production | Same main instance | Administration |
dev.monsite.com/ |
Configured hosting | Integration track following dev |
Integration preview |
mon-essaie.dev.monsite.com/ |
Production | Experimental branch instance | Editable preview |
www.frenchexdev.net/diem |
Configured hosting | Planned product instance | Public product presentation |
The role and access policy determine what a visitor can do. An editable preview may run in production hosting without granting editing rights on the main instance. Public indexing is independently configured; it is not inferred from the presence of a DNS record.
Shared data has an explicit scope
The main frontend and admin use the same data scope. A branch instance defaults to isolation and may be initialized with approved fixtures or a recorded content snapshot. A configuration may deliberately share a data source, but must establish model compatibility and applicable access rules.
The domain specification defines binding validation. The promotion specification defines movement between data scopes.
Previous: From Domain Model to Running Site · Next: Models, Workspaces and Release Artifacts · Series index · Section index