Skip to Content
Jumentix DocsReferenceDomain Designer Features and Usage

Domain Designer Features and Usage

This document is the technical guide for all Domain Designer MVP capabilities inside:

  • apps/service-management/

It covers what each feature does and how to use it in practice.

1) Canvas and Navigation

Features:

  • Domain rectangles (color-coded)
  • Entity cards inside domains
  • Pan, zoom, fit, reset
  • Snap-to-grid
  • Compact/full view
  • Large-canvas performance mode
  • Mini-map navigation
  • Undo/redo

How to use:

  1. Create domains and entities from the left panel.
  2. Drag domain headers and entity headers to reposition.
  3. Use:
    • Ctrl/Cmd + mouse wheel for zoom
    • Space + drag for panning
    • Fit and Reset View for quick framing
  4. Turn on Large Canvas for high-density diagrams.
  5. Use the mini-map to focus a domain quickly.

2) Relationship Design

Features:

  • Form-based relationship creation (from, to, cardinality)
  • Pick-on-canvas mode
  • Anchor-to-anchor drag connectors
  • Relationship reverse
  • Auto FK generation
  • Label offset controls (x, y)
  • Bend path controls (bendX, bendY)
  • Anchor behavior (auto, center)
  • Routing style (curved, orthogonal)

How to use:

  1. Select source and target entities and click Connect.
  2. Or click Pick On Canvas and select entities directly.
  3. For anchor-aware connections, drag from edge anchors (top/right/bottom/left) between entities.
  4. Select a relationship in the list and tune:
    • label offset
    • bend points
    • anchor behavior
  5. Click Save Relationship.

3) Domain Context Metadata

Per-domain metadata:

  • Ubiquitous language
  • Owner team
  • Upstream dependencies
  • Downstream dependencies
  • Integration channel
  • Package dependencies
  • Shared value objects

How to use:

  1. Select a domain.
  2. Fill values in Bounded Context.
  3. Click Save Context.

These fields are persisted in the designer state and exported through JSON/package flows.

4) Entity Editing and Templates

Entity-level features:

  • Rename, move, duplicate, delete
  • Aggregate root flag
  • Invariants editor
  • Field CRUD with OpenAPI-aligned metadata
  • Field templates (tenantRef, auditTrail, softDelete, contactPack)
  • Entity templates:
    • crudAggregate
    • eventSourced
    • referenceData
    • tenantOwned

How to use:

  1. Select an entity.
  2. Use Entity Inspector for rename/move/rules.
  3. Add fields manually or apply field templates.
  4. Apply entity templates from Entities panel.

5) RBAC Policy Mapping

Per-entity action policy, aligned with the tenant RBAC authorization contract (TENANT-RBAC-AUTHORIZATION-CONTRACT.md, JUM-477):

  • Actions:
    • list
    • getById
    • create
    • update
    • delete
  • Role toggles (the contract’s normalized roles):
    • superadmin
    • admin
    • user
  • Tenant scope: derived from the selected roles, not a free flag. The runtime (Rbac.ts / TenantAuthorizationPolicy.ts) constrains admin and user principals to their own organization and gives superadmin a global boundary — there is no independent tenant-scope knob to honour, so the editor displays the derived value as a read-only checkbox. Stored policies are repaired to the derived value on load.
  • Legacy direct scopes (read_user, create_organization, …) remain runtime-supported and survive import/export, but are not editable in the inspector; validation accepts them as contract-expressible.
  • A role outside the contract vocabulary is rejected at save time with an actionable message, and model validation reports any such stored role as an error so the export quality gate blocks it instead of dropping it.

How to use:

  1. Select entity and action.
  2. Mark allowed roles; the tenant-scope indicator follows the roles.
  3. Click Save RBAC Rule.
  4. Review generated matrix in the RBAC list.

6) Message Contract Designer

Supported contract types:

  • event
  • command
  • request
  • response

Contract fields:

  • name
  • type
  • channel/topic
  • version
  • payload schema (JSON editor)

How to use:

  1. Select entity.
  2. Fill contract name/type/channel/version.
  3. Click Add Contract.
  4. Use payload button to edit schema JSON.

Exports include these contracts in:

  • OpenAPI extension (x-message-contracts)
  • AsyncAPI export

7) OpenAPI Advanced Composition

Per-entity controls:

  • oneOf, allOf, anyOf
  • schema refs list
  • external $ref list
  • discriminator property

How to use:

  1. Select entity.
  2. Choose composition mode.
  3. Add schema refs and optional external refs.
  4. Define discriminator if needed.
  5. Save composition.

8) Validation, Quality Gate, and Diff

Features:

  • Model checks with severity:
    • error
    • warn
    • info
  • Configurable minimum severity filter
  • Export block on critical issues
  • Schema baseline save/clear
  • Schema diff and migration hints

How to use:

  1. Click Validate Model.
  2. Adjust severity filter if needed.
  3. Enable block export on critical issues to enforce quality gate.
  4. Save a baseline, then run diff to detect changes.

9) Example and Code Generation

Generated outputs:

  • Request/response payload examples
  • Code skeleton preview:
    • model
    • repository port
    • use case
    • controller
    • handler

How to use:

  1. Select an entity for focused output, or keep none selected for full-canvas output.
  2. Click:
    • Generate Examples
    • Code Preview

10) Export and Import Targets

Export:

  • JSON model
  • OpenAPI 3.1
  • Markdown
  • JSON Schema
  • AsyncAPI
  • Boilerplate bundle
  • Domain package

Import:

  • JSON model
  • OpenAPI 3.1
  • Domain package

How to use:

  1. Use export buttons in Export panel.
  2. Use import buttons for JSON/OAS/package.
  3. For package export, selected domain is used as source package.

10.1) OAS 3.1 export contract (Requirement 036, JUM-474)

The OpenAPI 3.1 export produces a document compliant with Requirement 036 and the route-resolution check (ci-cd/check-oas-route-resolution.js):

  • Every operation carries a unique operationId on the canonical spec/1.0.0.yml verb scheme (getAll*, create*, get*ById, update*, delete*), qualified by the schema name (getAllBilling_Invoice).
  • Request bodies reference RequestCreate<Schema> / RequestUpdate<Schema> port input objects via $ref; 2xx responses reference the entity schema, its <Schema>ArrayOf wrapper or ResourceDeleteResponse. No inline request/response schemas, and every referenced schema has a description.
  • Port input/output wrappers are marked 'x-port-object': true and skipped on OAS import, so a round-trip creates no phantom entities.
  • Error responses use the canonical ERROR-CONTRACTS-AND-RESPONSES codes (400/401/403/404/409).
  • Entities whose names collapse to the same OAS schema name or route path (for example Foo Bar vs Foo-Bar) fail the export quality gate instead of silently overwriting each other in the document.

10.2) Lossless OAS round-trip (JUM-478)

The OAS crossing is a contract between the exporter and the importer: what OAS cannot express natively crosses as agreed x- extensions and is normalized back into entity.meta on import, so export → import → export reaches a fixed point with an empty model-level loss list (asserted by designerRoundTrip.test.ts).

  • x-aggregate-root and x-invariants carry the aggregate declaration and invariants when set.
  • x-rbac carries the entity’s normalized RBAC policy, emitted only when it diverges from the designer default (an absent x-rbac normalizes back to the default policy, with tenantScoped derived from the roles per the tenant RBAC contract).
  • x-fieldless: true keeps an entity’s empty field set across the crossing (an unmarked schema without properties still gets the importer’s default id/createdAt/updatedAt fields).
  • x-field-flags: { pk, fk, unique } carries a field’s flags only when they diverge from the importer’s name heuristic (id → PK/unique, *Id → FK).
  • x-relations rows carry { name, fromSchema, toSchema, fromCardinality, toCardinality } — schema names, not model ids — and the importer restores relationships re-keyed to the recomputed entity ids, dropping rows whose endpoints did not import.
  • Foreign documents without designer markers (the canonical spec/1.0.0.yml) are recognized by the same port-object conventions: Request<Action>* and *ArrayOf names, ResourceDeleteResponse, “Port input/output object” descriptions that are not <Name> resource entity contracts, and non-object schemas never become entities.
  • Named remaining losses for foreign documents: example/default/ minItems/maxItems facets and array item $ref linkages (value-object references flatten to the itemsType vocabulary), domain bounded-context blocks, canvas positions, and legacy (non-canonical) operationIds.

11) Smoke Coverage

Service Management smoke tests:

  • apps/backend-template/test/integration/ServiceManagement/domainDesigner.smoke.test.ts
  • apps/service-management/test/unit/mvp.roadmap.features.test.ts

Run:

bun run test:integration:service-management
NODE_ENV=dev bun x jest apps/service-management/test/unit/mvp.roadmap.features.test.ts --runInBand
Runtime Environment ContractsService Management Module Architecture