npm package: @seij/entity-graph
Description: Runtime entity graph for business domains. It builds a live model from DTOs provided by backend services (bounded contexts). Those DTO provides abstract definitions of a domain model (not the data, the definitions), so the UI can discover entities, proper
Latest version: 0.1.2

# entity-graph

Runtime entity graph for business domains. It builds a live model from DTOs
provided by backend services (bounded contexts). Those DTO provides abstract
definitions of a domain model (not the data, the definitions), so the UI can
discover entities, properties, and relationships on the fly and generate screens
dynamically.

## What it provides

- DTOs and interfaces to describe entities and their properties.
- Relationship definitions with cardinality (to-one / to-many).
- A registry that assembles entities and relationships from extension
  contributions.
- Type-based validation hooks for property values.
- Helpers to build default values for entity creation.

## Why use it

- Consume backend-provided model descriptions (DTOs) per bounded context.
- Discover available entities and relationships at runtime.
- Generate baseline UI (lists, forms, detail views) from metadata.
- Keep validation and field metadata consistent across screens.
- Scale across many models and multiple apps without hardcoding schemas.

## Benefits

- Faster UI delivery: a generic UI can be generated from the graph.
- Reduced duplication: one model description feeds multiple screens and apps.
- Safer changes: new fields or entities appear without rewriting UI logic.
- Extensible types: validation and behavior can be added per type via
  extensions.

## What is truly novel here

- **Runtime domain model driven by backends**: most tools start from a central
  schema (DB, OpenAPI, JSON Schema). Here, the schema comes from bounded
  contexts themselves and can be composed dynamically on the frontend. It is
  more DDD-aligned than most generators.
- **Entity graph + extensible type validation**: not just a “schema”, but a
  usable graph (relations + cardinalities) and behavior per type. This unlocks a
  truly generic UI (navigation, CRUD, validation) without hardcoded domain
  conditionals.
- **Contribution-based (plugin-based) extensibility**: entities, relationships,
  and types are extendable via a contribution mechanism, so new domains or new
  sources of descriptions, can be added without touching the core. It is a
  platform model rather than a simple library.

## Blind spot covered compared to similar tools

- **Multi-domain / multi-backend**: most tools assume a single central model (or
  one backend). Here, you can aggregate several sources and compose the graph.
- **Truly runtime UI**: many tools generate code from a schema. Here, the
  application adapts at runtime, which is useful when models change often or
  when each client has a different scope.
- **Consistent, delegated validation**: validation is carried by the type
  system, not rewritten in each form. This reduces drift between UI and domain
  rules.

In short: the novelty is not a tool for “generating forms”, but having a frontend that
adapts to a dynamic, multi-source domain model with an extensible type system.

That combination is rare.

## How it works

- Entities and relationships are declared as DTOs coming from backends.
- Extensions contribute entity, relationship, and type definitions.
- The `EntityGraph` service builds a graph, checks for duplicates, and validates
  that all property types are handled.
- Property definitions expose validation through type extensions.