MASD
Table of Contents
1. Summary
MASD is the methodology the code generator implements, and the cluster is best read as one idea unfolded. The idea: describe a domain once, in a space that knows nothing about any programming language, then project that description into as many languages and file layouts as you need. Everything else is the machinery that makes the projection well defined.
So the order is the projection itself. Start with the methodology and its metamodels. Then the logical space, which is what you author. Then the technical and physical spaces, which are what you project into. Then facets, which group the projected artefacts. Then variability, which is how one logical model yields different output without being forked. Finish with how this project actually instantiates all of it, which is where the abstractions acquire file paths.
Reading the spaces out of order is the common mistake. Physical space looks approachable because it is just files, but its concepts are defined against the logical model they came from, and it reads as arbitrary without it.
2. Reading order
2.1. The methodology
MASD — start here. The logical-physical split and the four metamodels. Read it as a map: it names every part the following pages treat in detail, and the names do not change afterwards.
2.2. What you author
Logical Space — the Logical Metamodel, its packages, and its levels of abstraction. This is the space a modeller works in and the only one where a domain concept exists as itself rather than as a projection of itself.
2.3. What you project into
Technical Space — a language or platform with its conventions. Read before physical space, because it is what makes a physical artefact meaningful: the same logical class is a different file in C++ than it is in SQL.
Physical Space — files, folders, file morphology, and the component structure. Now the file layout reads as a consequence rather than a convention.
2.4. How the projected artefacts group
Facet — a container for related artefacts of one technical space. Facets are what the generator's templates are organised by, so this is the page that connects the methodology to the template library.
2.5. How one model yields different output
Variability — the Variability Metamodel: features, profiles, and non-structural variation. Read after facets, because variability is expressed as choices within a projection and there is nothing to vary until the projection exists.
2.6. How this project does it
Applied MASD — the mapping from each MASD concept onto ORE Studio's own directories, models and templates. This is where the vocabulary acquires paths, and it is the page to return to when a concept is clear in theory and unclear in the tree.
Entity Lifecycle — the cross-facet ordering: which layer of an entity is generated before which, and why. Read last, and read it before doing any entity work: it is the operational consequence of everything above, and the order it prescribes is not negotiable.
3. What this cluster does not cover
The skills framework borrows MASD's shape — a target with a type, and operations registered against the type — but it is a separate cluster with its own entry point.
4. See also
- Knowledge — the index this structure note hangs from.
- Skill architecture — the same dispatch shape, applied to skills rather than code.
- Zettelkasten — what a structure note is and why the order is authored rather than computed.