Module Generation and Derived Products
Status: Public design proposal and product vision. This series presents Diem CMF .NET’s intended architecture and capabilities. Proposed features remain subject to implementation and validation; existing components are identified separately.
A reusable framework should let an author package a useful part of the development experience. One such product could be a Diem module generator that accepts a domain model and produces compatible frontend and administration contributions.
For Acme Catalogue, a generator can derive Product administration, conventional query contracts and bindings for listing and detail views. A custom enquiry workflow remains application behavior with its own declared extension points.
The generator as a product
The generator is a composition of capabilities: model validation, code generation, admin descriptions, renderer contributions and package assembly. An author can distribute it as an extension, select a subset of outputs and add domain-specific conventions.
A specialized catalogue generator might offer Product, Category and media relationships. Another generator might target internal tools, directories or documentation portals. They should share the contracts they genuinely have in common while retaining their own domain rules.
Preserve customization across regeneration
The proposal distinguishes three kinds of output:
| Material | Ownership |
|---|---|
| Model definitions and authored behavior | Application author |
| Generated sources and derived descriptors | Generator |
| Editable initial templates | Author after explicit creation or adoption |
A generator must identify its owned files. It can replace those files on the next generation, but cannot silently overwrite a handwritten service or a template that has become user-owned.
Custom code should attach through declared interfaces, partial hooks where appropriate, or separate contributors. If a model removes a required field, generation should report the resulting incompatibility. It should not quietly erase the custom code to make the build pass.
Reuse the result
The generated package may contribute a domain type, an admin module and several renderers. A consuming instance selects compatible contributions. It can reuse the same Product model with a Hugo template and a Blazor view without requiring those implementations to be identical.
An extension can also provide a new type of contribution. A search package might define a provider contract; another package implements it. The host learns the new contribution family through the installed contracts and their registry, rather than through a new hardcoded case in every product component.
Assemble from DLLs or source
A team can consume a versioned package containing compiled DLLs and assets. It can also provide a Git repository that the Lab builds into compatible artifacts. A workspace without Git can produce a recorded source snapshot.
These are input routes to the same assembly and compatibility process. A DLL import does not imply editable C# sources, and a Git import does not imply that its latest commit is already active.
A concrete authoring loop
The module author models Products, chooses outputs, adds an enquiry action and generates the module. They build and test it against the selected .NET 11 toolchain, then package its contributions and dependencies. A consuming site installs that package in a development track and validates it before promotion.
The generation contract defines deterministic inputs and file ownership. The marketplace lifecycle follows the package into a consumer instance.
Previous: The Integrated Lab · Next: Extensions and Marketplace · Series index · Section index