Modulith 0.10.0

Modulith

dotnet new templates for a .NET modular monolith: a Blazor Server host plus a set of layer projects (Contracts/Domain/Application/Infrastructure/Web) per feature, each feature owning its own DbContext and its own Postgres schema.

Templates in this package

• dotnet new modulith — scaffolds a new modular-monolith solution.
• dotnet new modulith-feature --appName <App> -n <Name> — run from a scaffolded solution's root to add one feature's layer projects (Contracts/Domain/Application/Infrastructure/Web) plus their matching test projects, registered in the solution automatically.

A scaffolded feature is added to the .slnx but not yet wired into the host. Reference its Web project from src/<App>.Web/ and call builder.Configure<Name>Feature(); in Program.cs — the generated solution's own README spells out both commands.

What a scaffolded solution contains

• Two sample features, so the isolation rules are enforced against more than one slice: Orders shows the layering with command/query handlers, a repository and its own OrdersContext, and Payments is a second, minimal slice with its own entity and schema.
• EF Core on Npgsql with snake_case naming and a per-feature migrations history table.
• Mediator with logging, exception, and validation pipeline behaviours; FluentResults for handler outcomes and FluentValidation for input.
• Cross-feature communication that keeps the slices isolated: a read-only per-feature module API, published through a Contracts project that is the only part of a feature its neighbours may reference, with architecture tests enforcing it. Within a feature, domain events dispatch inside the saving transaction.
• xUnit v3 test projects per layer, bUnit for components, and ArchUnitNET architecture tests.
• A devcontainer with .NET, the dotnet-ef CLI, and Postgres.

DB Migrations

Each feature has its own DbContext and schema, so every dotnet ef command needs a --context. The generated solution ships two scripts in its root that handle that:

bash add-migration.sh Orders InitialOrders   # <FeatureName> <MigrationName>
bash update-database.sh                      # applies every feature's pending migrations

update-database.sh discovers the contexts from the host's DI container, so a feature is picked up as soon as Program.cs registers it.

The equivalent raw commands, if you need to deviate (replace MyApp/Orders with your own):

dotnet ef migrations add InitialOrders -o Data/Migrations --context OrdersContext \
  --project src/Features/Orders/MyApp.Features.Orders.Infrastructure/ \
  -s src/MyApp.Web/

dotnet ef database update --context OrdersContext \
  --project src/MyApp.Web/ -s src/MyApp.Web/

The dotnet-ef CLI comes preinstalled in the generated devcontainer; outside it, install with dotnet tool install --global dotnet-ef. Microsoft.EntityFrameworkCore.Design is already referenced by the web host, so there is no package to add.