Appearance
Definitions and Metadata
Verified module boundariesPlatform model interpretationExtension guidance
Deep links:
Why these two modules matter
In NGB, metadata and definitions are the platform’s descriptive language.
- Metadata answers: what fields/tables/lookups/presentation elements exist?
- Definitions answers: what catalog/document/report/register behavior is part of the platform and how is it assembled for execution?
Verified anchors
NGB.Metadata/NGB.Metadata.csprojNGB.Definitions/NGB.Definitions.csproj
Working model
Metadata layer
Metadata is the neutral descriptive substrate. It should be stable, reusable, and free from request-execution concerns.
Typical responsibilities include:
- entity and field descriptors
- table/head/part structure
- presentation metadata
- lookup metadata
- typed declarative shape that runtime can consume
Definitions layer
Definitions package metadata into executable business features.
Typical responsibilities include:
- registering catalogs/documents/reports
- connecting definitions to accounting/register semantics
- exposing reusable definition sets to runtime and hosts
- acting as the bridge from “description” to “platform feature”
Why the split is useful
Without this split, platforms tend to mix:
- DTO contracts
- UI hints
- business descriptors
- request-time behavior
- storage details
NGB’s split makes it easier to:
- keep the platform extensible
- reuse the same descriptive model in multiple verticals
- avoid binding API/storage decisions into the definition language too early
How to use this in extension work
When adding a new business capability, ask:
Is this descriptive shape?
Put it closer to metadata.Is this registered platform feature?
Put it closer to definitions.Is this execution/orchestration?
Put it in runtime.Is this SQL/storage implementation?
Put it in PostgreSQL infrastructure.