The domain layer

What in the kit is not the kit: operation icons, schema adapters and product rules have their own package entry.

One question, not a list

The package has two main entries, and the line between them is not a matter of taste. It is one question you can ask of any module: would this still make sense in a product that is not Forgmatic?

A form field description would. An icon key our database stores would not. The answer decides the entry, which is why it also works on a module nobody has written yet — unlike a list, which has to be remembered.

WhatFrom whereWhy there
A form field description@forgmatic/ingotMakes sense in any product: a key, a kind, a label, a range.
Turning an operation schema into fields@forgmatic/ingot/forgmaticIt reads names this platform's API chose. Another platform has its own.
Interface icons@forgmatic/ingotAn arrow, a bin, a magnifier. No interface is built without them.
Manufacturing operation icons@forgmatic/ingot/forgmaticForty-three drawings and keys the backend stores. Whoever does not draw them should not download them.
How deep in dialogs I am@forgmatic/ingotOnly the kit knows: it is the thing counting open dialogs.
How deep a quick-create may still be offered@forgmatic/ingot/forgmaticA product decision. Another application may allow three levels, or none.

Who takes what

  • The Forgmatic admin takes both entries. It draws operation icons and reads schemas our API sends.
  • The public site takes the main entry and the public-page blocks. It needs the domain layer on no page at all.
  • A third-party application takes the main entry. It may take the domain layer too — it is a public part of the package — but it almost certainly wants its own.

The main entry still passes the domain layer through, marked deprecated, so the split breaks nobody's build overnight. In the next major those pass-through exports go away, and the whole migration is a changed import path.