Shared Property Sets
Define reusable groups of properties that can be applied across multiple entities with live inheritance, auto-apply rules, governance metadata propagation, and validation across all consuming entities. Common patterns like audit fields, soft delete, timestamps, and tenant isolation are defined once and maintained in one place.
In most data models, certain groups of properties appear on nearly every entity. Audit fields such as createdBy, createdDate, modifiedBy, and modifiedDate are repeated across dozens or even hundreds of tables. Soft delete patterns add isDeleted, deletedDate, and deletedBy. Multi-tenancy introduces tenantId. When these properties are defined individually on each entity, a change to the pattern (such as renaming createdDate to createdAt, or adding a new audit field) requires updating every entity manually. Shared property sets solve this by defining these common groups once and applying them to entities with live inheritance.
What are Shared Property Sets?
Common Use Cases
Auto-Apply Rules
Manually attaching property sets to every new entity is error-prone. Auto-apply rules handle this automatically based on criteria you define.
| Rule Type | Example | Effect |
|---|---|---|
| By Group | Apply 'Audit Fields' to all entities in the 'Core Domain' group | Any entity placed in the Core Domain group automatically receives audit field properties |
| By Name Pattern | Apply 'Tenant Isolation' to entities matching '*Order*' or '*Invoice*' | Entities whose name contains Order or Invoice receive tenant isolation properties on creation |
| Universal | Apply 'Soft Delete' to all entities | Every entity in the model receives soft delete properties. New entities get them automatically |
How It Works
Validation Across Consumers
When a shared property set changes, the model validation engine runs checks across all entities that use it. If a property type change introduces incompatibilities with existing database profiles, search profiles, or API serialisation profiles, the validation engine flags these immediately. You see the full impact of a property set change before it propagates, not after.
The central model file is the single source of truth for every entity, relationship, and property in a NeoArc project. Abstract database-agnostic types, key roles, per-property projections for persistence, search, and API, governance classifications (PII, confidential, retention policies), shared property sets with live inheritance, comprehensive validation rules, and import/export across a wide range of formats.
Manage the full lifecycle of architectural entities with active, planned, and deprecated states, succession tracking via replaced-by and evolved-from edges, and automated impact analysis.
The model graph monitors every change you make: property renames, type changes, key role modifications (PK, FK, NK), required and unique flag changes, constraint modifications (min/max length, patterns, enums), relationship cardinality changes, edge deletions, schema drift, and protocol-level breaking changes. Comprehensive validation rules, schema drift detectors, protocol compatibility checks, and full impact analysis mean that no architectural change goes undetected.