Appearance
Layering and Dependencies
Verified project referencesDependency interpretation
Cross-reference:
How to read this page
This page answers two questions:
- What is allowed to depend on what?
- Why is that dependency direction useful in practice?
Verified project-boundary anchors
The following .csproj files establish the currently verified dependency skeleton:
NGB.Runtime/NGB.Runtime.csprojNGB.PostgreSql/NGB.PostgreSql.csprojNGB.Api/NGB.Api.csprojNGB.Metadata/NGB.Metadata.csprojNGB.Definitions/NGB.Definitions.csprojNGB.Accounting/NGB.Accounting.csprojNGB.OperationalRegisters/NGB.OperationalRegisters.csprojNGB.ReferenceRegisters/NGB.ReferenceRegisters.csproj
Core dependency picture
NGB Platform is organized as a layered set of reusable projects.
Metadata
NGB.Metadata is intentionally close to the bottom of the business-model stack. It references only the shared foundation it needs.
Meaning: metadata is meant to stay description-oriented, not orchestration-oriented.
Definitions
NGB.Definitions sits above metadata and composes reusable platform description with accounting/register/persistence concepts.
Meaning: definitions are where business/application shape becomes concrete enough for runtime consumption.
Runtime
NGB.Runtime depends on contracts, definitions, metadata, persistence abstractions, and the specialized business engines.
Meaning: runtime is the orchestration center, not the low-level storage implementation.
PostgreSQL
NGB.PostgreSql depends on persistence abstractions and business modules, plus Dapper/Npgsql/Evolve.
Meaning: it is the infrastructure realization of platform abstractions, not the place where high-level workflow policy should live.
API
NGB.Api depends on ASP.NET Core concerns plus contracts/application abstractions/runtime.
Meaning: API surface should expose the platform, not become the platform.
Practical rules
Rule 1 — runtime should stay provider-agnostic
Runtime can coordinate persistence abstractions, but concrete SQL/Dapper/Npgsql details belong in NGB.PostgreSql.
Rule 2 — definitions describe, runtime executes
If a concern is primarily “what exists” or “how it is described,” it belongs closer to metadata/definitions. If it is “how requests are executed,” it belongs in runtime.
Rule 3 — hosts compose, they do not own platform logic
Vertical API/background/watchdog hosts should wire the platform together through dependency injection, configuration, and module registration.
Rule 4 — PostgreSQL should not become a second runtime
Infrastructure can enrich performance and execution, but business workflow semantics should not be split randomly between runtime and storage provider layers.
Where this matters most
These layering rules are most visible in:
- document CRUD and lifecycle orchestration
- posting/effects execution
- report planning vs SQL execution
- migration discovery and host composition