Modeling overview
Modeling in modelARch means turning product knowledge into structured concepts that can be validated and projected consistently. You can author them through conversation and visual tools; you do not need to edit the underlying representation directly.
The model at a glance
Section titled “The model at a glance”| Concern | Main concepts |
|---|---|
| Product structure | Areas, objects, fields, value objects, enums |
| Behavior | Actions, mutations, events, reactions, timers |
| Decisions | Rules, lifecycle transitions, domain errors |
| People and access | Actors, roles, permissions, row scopes, ownership |
| Read side | Queries, filters, sorting, computed fields, reports |
| Experience | Activities, stories, processes, surfaces, views, transitions |
| Presentation | Brand, tokens, layout intent, view overrides |
| Integrations | External systems, capabilities, callbacks, auth contracts |
| Platform capabilities | Add-ons and infrastructure selections |
These concepts form one graph. A command belongs to an object, can be invoked by specific actors, mutates known fields, emits an event, appears as an affordance in a view, and can trigger an external effect. Keeping those links explicit is what lets the generator coordinate backend, frontend, tests, and documentation.
Problem space and solution space
Section titled “Problem space and solution space”modelARch keeps a strategic distinction:
- The problem space groups business capabilities into core, supporting, and generic subdomains.
- The solution space defines bounded contexts and aggregates that implement those capabilities.
The product UI uses approachable terms such as areas and objects while preserving the stronger structural boundaries needed for generation.
Author intent, derive projections
Section titled “Author intent, derive projections”Not every field in an exported model is manually authored. Some values are derived:
- canvas positions are UI state;
- relationships between areas can be inferred from the model graph;
- screens can be derived from actors, queries, and objects;
- view patterns can be inferred from semantic shape;
- process participants can be derived from their ordered steps.
Derived data must have one canonical derivation. If the user needs a different result, the model captures an explicit override or a new source decision rather than allowing projections to drift.
Model only what matters
Section titled “Model only what matters”A complete model is not the largest possible model. It is one that makes all implementation-significant decisions explicit.
Do model:
- business meaning, constraints, access, lifecycle, and exceptions;
- integration contracts and failure expectations;
- experience choices that must survive regeneration;
- operational requirements that change generated topology.
Do not model:
- individual production rows;
- secret values;
- transient CPU or queue depth;
- arbitrary generated file layout;
- implementation details with no semantic consequence.
Validation is part of modeling
Section titled “Validation is part of modeling”The model is useful because it can be checked. References, scopes, state transitions, field sources, process order, and experience bindings must resolve. A structurally valid model can still be a poor product, so discovery also records rationale and challenges omissions.
Start with Areas and objects or consult the Evolutionary Model reference.