MMCA.Templates 1.4.0

MMCA.Templates

dotnet new templates for the MMCA.Common framework: .NET 10, DDD, Clean Architecture, and CQRS, built as a modular monolith you can extract services out of later without a rewrite.

dotnet new install MMCA.Templates
dotnet new mmca-app -n Contoso.Support --module Orders --aggregate Order
cd Contoso.Support
dotnet build Contoso.Support.slnx
dotnet test  --solution Contoso.Support.slnx

That generates a warning-free, test-passing, migration-ready solution: one business module across all five layers, a REST API host, a Blazor Server + MudBlazor UI host, an Aspire AppHost, a per-database migrations project, and domain, application, and architecture-fitness test projects.

Templates

mmca-app parameters

--flat, --no-status, --no-description and --no-owner are shape decisions, not toggles: the code for an axis you turn off is never generated, so there is nothing to delete afterwards. Passing any of the four also drops the sample migrations, because they describe the full shape; run dotnet ef migrations add InitialCreate against the shape you asked for. Plural forms are derived by a simple English pluralizer (Item → Items, Entry → Entries, Box → Boxes), so an irregular noun needs one rename by hand.

Two shapes worth naming, because they are what most adopters reach for first:

dotnet new mmca-app -n Contoso.Catalog --module Products --aggregate Product \
  --flat --no-status --no-owner --title Name
dotnet new mmca-app -n Zeta.Orders --module Orders --aggregate Order --child Item \
  --no-owner --no-description --title CustomerName --event-verb Placed

--title and --event-verb are plain renames rather than shape decisions, and both are substring replacements: a multi-word --title CustomerName reaches the two shipped error messages as well as the identifiers, so "Ticket title cannot be empty." arrives as "Order customerName cannot be empty." Identifiers have to compile; those two strings are a one-line edit in the module's error resources after generating.

Adding a module to a generated solution

mmca-app ships build/add-module.ps1 inside every solution it generates, and that is the supported way to add the second module. It runs mmca-module for you and then performs all seven wire-ups the template can only print, plus the first EF migration:

pwsh build/add-module.ps1 -Name Orders -Aggregate Order -Child Item -EventVerb Placed

It must be run from the solution root, and it discovers everything else there: the solution file (which is also the app's root namespace), the module already present, and the web host, AppHost and architecture-test projects, all by glob. Nothing about the app that generated it is baked in, which is why the file is declared copyOnly in mmca-app's template.json: it ships verbatim, with no token replacement, so the flag names it passes through survive whatever --title / --event-verb / --child values the solution was generated with. build/templates/stage.ps1 guards both halves of that (the declaration, and that the script names none of the seed's own types or paths).

Every edit is anchored, a missing anchor aborts the run with the manual edit printed instead, a name already under Source/Modules is refused before anything is generated, and each already-applied step is skipped rather than duplicated. build/templates/smoke.ps1 adds its second module through this script, so the wire-ups are covered by the same code path adopters run.

mmca-module parameters

Run this from your solution root. It prints the seven wire-ups it cannot perform for you (a solution generated by mmca-app should use build/add-module.ps1 above instead, which performs them).

mmca-command and mmca-query parameters

Run these from an existing module's UseCases folder.

--domain-method is the one thing the scaffold cannot invent. Add that method to your aggregate returning Result before the slice compiles, or you get 'Order' does not contain a definition for 'Cancel'.

Full reference: https://ivanball.github.io/docs/guides/common-TEMPLATES.html. Getting started (six steps to a running app): https://ivanball.github.io/docs/guides/common-GETTING-STARTED.html. What the generated code does, phase by phase: https://ivanball.github.io/docs/guides/common-BUILD-BY-HAND.html.

How this package is built

The template content is the MMCA.Helpdesk reference application itself, staged at pack time. There is no second copy of the solution, so the template cannot drift from the app whose CI keeps it building.