Model-First Architecture
NeoArc Studio builds every architectural artefact from a single, authoritative data model. API schemas, database DDL, search indexes, governance documentation, and visual diagrams are all projections of one source of truth. Change the model, and every downstream artefact updates. Break a contract, and the system tells you before anything reaches production.
Every architecture team faces the same fundamental problem: data definitions are scattered across dozens of artefacts. The database schema says one thing. The API contract says another. The documentation says something else entirely. When a field is renamed in the database, nobody updates the API spec. When a new property is added to the API, nobody updates the search index. When a compliance requirement changes, nobody knows which systems are affected.
This is not a tooling gap. It is a structural one. Traditional architecture tools treat each artefact as independent. A diagram is a file. A schema is a file. They sit next to each other in a folder with no awareness of each other. The relationships between them exist only in people's heads.
NeoArc Studio takes a fundamentally different approach. Every entity, property, and relationship is defined once in a central data model. Everything else - API schemas, database DDL, search indexes, Data Views, governance documentation - is a projection of that model. The model is the source of truth. The projections are derived. And the Architectural Intent Graph traces every connection between them.
The Problem with Artefact-First Architecture
Consider what happens in a typical architecture workflow when a team needs to rename a field from userName to displayName.
This is not a hypothetical scenario. It happens in every organisation, on every project, continuously. The cost is not just wrong documentation. It is broken integrations, compliance gaps, wasted engineering time, and architectural decisions made on outdated information.
How Model-First Changes Everything
In NeoArc Studio, the same rename takes one action. You rename the property in the model. Everything else follows.
The Architecture of Model-First
The model-first approach has four layers, each building on the one below it.
One Property, Three Projections
The most powerful aspect of model-first design is that each property can be configured independently for each output domain. A single property can appear differently in the database, the search index, and the API, all controlled from one place.
| Aspect | Persistence Projection | Search Projection | API Projection |
|---|---|---|---|
| Inclusion | Include or exclude from physical storage | Include or exclude from search index | Include or exclude from API contract |
| Naming | Column name via database profile naming convention | Field name via search profile naming convention | Field name via API serialisation profile naming convention |
| Type Resolution | Abstract type mapped to concrete DB type (e.g., string to NVARCHAR) | Abstract type mapped to search field type (e.g., string to keyword) | Abstract type mapped to API type with format hints |
| Behaviour | Column mapping, nullable, indexed | Searchable, filterable, sortable, facetable, retrievable, aggregatable, highlightable | Read-only flag, field name override |
| Advanced | Parameterised templates using property constraints | Analyser, normaliser, synonym map, vector dimensions, similarity metric | Date format (ISO 8601 / Unix), enum format (string / numeric) |
What This Enables
Model-first architecture is not an abstract principle. It enables concrete capabilities that are impossible in artefact-first tools.
Who Benefits
The Model-First Capability Map
Every capability in NeoArc Studio traces back to the central model. The sections below cover each capability in detail.
| Capability | What It Does | Why It Matters |
|---|---|---|
| Data Model | Defines entities, properties, relationships, groups, constraints, and governance metadata in a single file | One source of truth that everything else derives from |
| Multi-Domain Projections | Each property carries independent persistence, search, and API configurations | Different teams see the same data through domain-appropriate lenses without duplication |
| Database Profiles | Maps abstract types to vendor-specific concrete types with parameterised templates | Design once, deploy to any database vendor |
| Search Profiles | Configures search engine behaviour across supported engines with operational strategies | Search index configuration is part of the architecture, not an afterthought |
| API Serialisation Profiles | Controls naming conventions, date formats, and enum representations per API target | Multiple API consumers get their preferred conventions from one model |
| Model-Derived Data Views | Data Views read entity data from the model at render time via persistence and search modes | Views can never drift from the model because they do not duplicate data |
| Shared Property Sets | Reusable property groups with live inheritance applied across entities | Change an audit field pattern once and every entity updates immediately |
| Model Validation | Validation rules across structural, semantic, and domain categories | Catches errors at design time, before they become production incidents |
| Import and Export | Broad import and export format support for bidirectional interoperability | Start from what you have and generate what you need |
| Entity Lifecycle | Active, planned, and deprecated states with replacement tracking and migration tooling | Controlled evolution with full traceability of what replaced what and why |
| Architectural Intent Graph | A comprehensive set of node and edge types connecting every artefact in the workspace | The traceability backbone that makes impact analysis, lineage, and governance possible |