Logical Space
Table of Contents
The logical domain is the language-neutral meta-model of MASD: the abstract layer that describes what domain concepts can exist and what structure they have, independently of any programming language, file format, or deployment platform. Logical entities are defined once here and then projected into physical space to produce concrete artefacts.
The distinction is adapted from Lakos's Large-Scale C++ Software Design:
Logical design addresses all the type-related aspects of design — classes and their relationships. Physical design addresses the placement of logical entities, such as classes and functions, into physical ones, such as files and libraries.
In MASD, logical design is fully technical-space-agnostic: a value entity
carries only its fields and relationships, not any language-specific
annotations. The technical space, facet, and variability configuration
determine how that entity ultimately manifests on disk.
See Domain Architecture for the formal treatment.
The Logical Metamodel (LMM)
The Logical Metamodel houses the meta-elements that model logical entities. It is designed expressly for code generation (an approach inspired by Piefel and Neumann) and is composed by generalisation from physical patterns and alignment with technical-space metamodels, rather than by replication. The LMM is organised into packages:
Figure 1: Figure 29 (Dogen): packages within the LMM. Source: Domain Architecture.
The packages are: Structural (closest to language constructs), Build, ORM, Visual Studio, Variability, Templating, Mapping (PIM support), Decoration, Serialization, and Physical. The Structural package is the one most readers will work with.
Levels of abstraction in the Structural package
The Structural package is itself organised as an abstraction ladder, from the concrete up:
- Traditional meta-types — module, enumeration, builtin, object.
- Idiomatic meta-types — exception, primitive, entry point.
- Design patterns — e.g. visitor (with singleton and builder in development).
- Object templates — the highest abstraction; they exist at modelling-time only.
Figure 2: Figure 31 (Dogen): the abstraction ladder in the Structural package. Source: Domain Architecture.
Logical entity types
In day-to-day modelling the structural meta-types appear as a fixed set of logical entity types. The type determines which facets are available and what physical artefacts can be produced.
| Type | Description |
|---|---|
object |
A class with identity, relationships, and operations. The primary type. |
value |
Immutable; defined entirely by its fields; no independent identity. |
enumeration |
A closed set of named symbolic values. |
primitive |
A named alias for a language builtin (e.g. account_id wrapping int64_t). |
exception |
An error type that can be thrown and caught. |
concept |
An abstract interface specifying a contract without implementation. |
module |
A namespace grouping; produces no artefacts of its own. |
builtin |
A language primitive (int, =string=…) that maps to an existing type. |
The logical address
Just as physical artefacts have an address, logical elements occupy points in logical space, written as:
[product].[component].[internal].[element name]
Figure 3: Figure 32 (Dogen): an example model annotated with LMM meta-types. Source: Domain Architecture.
Default facets per entity type
Not every entity type activates every facet. The table below shows the default active facet set for each logical type in Dogen's C++ technical space — the canonical definition from the reference implementation:
| Entity type | types |
hash |
io |
serialisation |
odb |
test_data |
|---|---|---|---|---|---|---|
object |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
value |
✓ | ✓ | ✓ | ✓ | — | ✓ |
enumeration |
✓ | — | ✓ | — | — | ✓ |
primitive |
✓ | ✓ | ✓ | ✓ | — | ✓ |
exception |
✓ | — | — | — | — | — |
concept |
✓ | — | — | — | — | — |
module |
— | — | — | — | — | — |
builtin |
— | — | — | — | — | — |
These defaults are overridden through the variability model.
Projections
A projection is a physical artefact produced from a logical entity through a model-to-text transformation. The same logical entity projects into many physical artefacts across many technical spaces and facets — a struct, a serialisation routine, an ORM mapping, a UI form — each a distinct expression of the same underlying logical truth. Modifying the logical entity (adding a field) propagates to all projections simultaneously through regeneration. The receiving side is described in Physical Space.
See also
- MASD — methodology overview and the conceptual model.
- Physical Space — how logical entities become physical artefacts.
- Technical Space — the language/platform ecosystem that hosts projections.
- Facet — the named role that determines which artefacts a projection produces.
- Variability — how active facets are configured per entity type.
- Applied MASD — how one product instantiates this logical space.