Featured work · Open source
The MMCA platform
A production-grade .NET 10 platform that demonstrates modern enterprise architecture end to end: an open-source framework of lockstep-versioned NuGet packages plus real applications that prove the patterns under live traffic. The design goal is one sentence: build the monolith now, extract a service later, without a rewrite.
Cleavestack ↗ is the commercial home of MMCA: build as one, ship as many.
The framework
MMCA.Common
A NuGet package framework for building modular-monolith applications with DDD, Clean Architecture, and CQRS, and the extension points to extract a module into its own microservice later. Every package releases in lockstep at one version and the set spans every layer; a metapackage installs the core six with a single reference.
- Shared MMCA.Common.Shared Result pattern, value objects, error handling, DTOs
- Domain MMCA.Common.Domain Entities, aggregate roots, domain events, specifications
- Application MMCA.Common.Application CQRS handlers, the decorator pipeline, the module system
- Infrastructure MMCA.Common.Infrastructure EF Core multi-engine, repositories, caching, outbox, message bus, multi-tenancy, audit trail, job scheduler
- API & transport MMCA.Common.APIMMCA.Common.Grpc Controllers, middleware, idempotency, JWKS, gRPC contracts
- UI MMCA.Common.UIMMCA.Common.UI.WebMMCA.Common.UI.Maui Blazor shared components, MudBlazor theme, web and MAUI clients
- Hosting MMCA.Common.AspireMMCA.Common.Aspire.HostingMMCA.Common.Gateway Aspire service defaults, OpenTelemetry, health checks, broker wiring, YARP gateway composition
- Testing MMCA.Common.TestingMMCA.Common.Testing.ArchitectureMMCA.Common.Testing.E2EMMCA.Common.Testing.UI Integration bases, architecture rule library, Playwright and bUnit harnesses
- Metapackage MMCA.Common MMCA.Common: one reference that bundles the six core packages (Shared, Domain, Application, Infrastructure, API, Aspire) so a standard app starts from a single PackageReference
Strict layered core
Shared → Domain → Application → Infrastructure → API/Grpc. The Result pattern carries expected failures, entities are rich aggregates with factory methods, and queries compose from specifications instead of LINQ spaghetti.
CQRS decorator pipeline
Thin command and query handlers wrapped by a Scrutor decorator chain: FeatureGate → Authorization → Logging → Caching → Validating → Timeout → Transactional → Handler. The order is load-bearing and registered once.
Extraction boundaries
Application code talks to abstractions; transport lives at the edge. A transport-agnostic message bus, gRPC contracts, JWKS cross-service auth, and Aspire hosting let a module become a service with no domain rewrite.
Proof, not slideware
Three reference applications
The framework is consumed by real apps. Each one exercises the patterns differently, and the conference app ran a live event on Azure.
MMCA.ADC
A production-deployed conference platform: four microservices (Identity, Conference, Engagement, Notification) behind a YARP gateway, cross-service JWKS auth, bidirectional gRPC, polyglot persistence, QR badge check-in with a live points leaderboard, and load testing at conference-day scale. It powered the Atlanta Cloud + AI Conference.
MMCA.Store
An e-commerce app refactored from a monolith into three microservices (Catalog, Sales, Identity) with Stripe payments, output caching, permission-based access control, and an accessible Blazor and .NET MAUI UI.
MMCA.Helpdesk
The deliberately minimal seed: a single Tickets module exercised through all five layers. It is the worked companion to the framework's getting-started guide and the easiest entry point for exploring the patterns.
A look inside
From one graph, laptop to cloud
Orchestrated locally with .NET Aspire, then deployed to Azure Container Apps from the same declarative model.


How it holds together
Architectural styles the codebase commits to
The recurring ideas every repo is built on, summarized from the onboarding primer's orientation chapter. Each is taught in full at its first concrete appearance in the reference library.
Domain-Driven Design
Aggregates enforce invariants inside their boundary, value objects model concepts with no identity, domain events announce meaningful state changes, and factory methods return a Result so an invalid entity cannot be constructed.
Clean Architecture
Source dependencies point inward toward a framework-free domain; the application layer defines ports and infrastructure implements the adapters. Enforced twice: a compile-time MSBuild layer guard and shared NetArchTest fitness functions.
CQRS
Commands mutate and return a Result; queries are side-effect-free. Both flow through a decorator pipeline (feature gate, authorization, logging, caching, validation, timeout, transaction), so cross-cutting concerns live in the pipeline, not in each handler.
One shared HTTP middleware pipeline
Every REST and gRPC service host builds its request pipeline from a single call that fixes the middleware order once, with the load-bearing adjacencies commented in code. Hosts differ by configuration, never by pipeline shape.
Vertical slice architecture
Within a module, a feature is one cohesive slice: command or query, handler, validator, DTO, and mapper together. Adding a feature means adding a slice, not scattering edits across horizontal folders.
Modular monolith, extractable services
Modules implement one contract and are registered in dependency order; each can later run as its own service host behind a YARP gateway without a rewrite, because application code talks to abstractions and transport lives at the edges.
Cross-service auth without shared secrets
Only the Identity service holds token-signing key material: every other service validates its RS256 tokens via JWKS / OIDC discovery, so no symmetric secret ever crosses a service boundary and key rotation is publish-once at the issuer.
Write-once UI, render everywhere
A page is authored once as a Razor component and hosted by both the Blazor web host and the .NET MAUI hybrid host: Web, Android, iOS, macOS, and Windows with no per-platform reimplementation.
Event-driven integration, with an outbox
Domain events are persisted in the same transaction as the data, then delivered at least once by a background processor, in-process for the monolith or over a broker once extracted. No save-then-publish dual-write bug.
Database-per-service
Each module or service owns its own database and its own outbox. Cross-source relationships auto-degrade to batch loaders, and the outbox is the cross-source consistency mechanism.
Engine-agnostic entities
A domain entity carries no persistence-engine choice: a one-token attribute on its configuration routes it to SQL Server, Cosmos DB, or SQLite with zero change to the entity or the application layer. Plumbing shipped and tested.
The Result pattern
Expected error paths return a Result carrying typed errors instead of throwing exceptions: the single most pervasive idiom in the codebase.
Soft-delete, audit, and erasure
Entities are never hard-deleted: global query filters hide them, audit fields are stamped centrally on every save, an opt-in field-level audit trail writes in the same transaction, and a separate anonymize path satisfies GDPR/CCPA erasure.
Multi-tenancy without a fork
An opt-in named tenant filter composes with the soft-delete filter, a write interceptor refuses cross-tenant writes, and a per-tenant connection-string override buys full database isolation, all from the same entity model.
Identifier type aliases
Every entity ID is a per-module type alias rather than a bare int or Guid, linked into every project, so an ID type changes in exactly one place.
Graded honestly
A two-axis architecture scorecard
Every repo is scored against a 34-category rubric on two axes, Maturity (how complete the decision is) and Implementation (how well it is realized in code), with evidence and recorded gaps rather than a single vanity number.
Why, not just what
Architecture Decision Records
111 ADRs capture the context and trade-offs behind each cross-cutting pattern, so the design is teachable, not tribal knowledge. Every entry below links to the full record.
Read the source of truth
The reference library
The full architecture documentation, maintained in this site's repository as its canonical home and rendered as browsable pages: every Architecture Decision Record, the governance scorecards, the guides and specifications, and the complete onboarding guide that walks the codebase type by type.
Start here
Use it, read it, or follow along
The framework is Apache 2.0 and published to nuget.org. The fastest way in is the reference app: one module wired end to end through all five layers, with the extraction path already in place. Commercial support (assessments, workshops, embedded advisory) is available through Cleavestack.
Try the reference app
MMCA.Helpdesk is a runnable seed built against the framework, and the worked companion to the getting-started guide. Every step in the guide maps to real code in that repo.
Install the packages
Every package releases in lockstep at one version. The MMCA.Common metapackage is one reference that installs the six core packages; add Grpc, UI, Gateway, or Testing.* as you need them.
Read the code
The framework and the reference app are public. The two production applications that track it are the source of the case-study material in the docs.
Get each deep dive by email
One message per article, no digests and no other mail.