Ivan Ball-llovera

↑↓ to navigate Enter to open "…" all these words ANDOR to combine

Proof & getting started · No. 53

The MMCA series: every pattern, one place

Ivan Ball-llovera Also on Medium ↗

A single map of the whole series. Start at the top if MMCA.Common is new to you, or jump straight to the pattern you came for.

MMCA.Common is an Apache-2.0 licensed .NET 10 framework that gives you DDD, Clean Architecture, and CQRS as a modular monolith that extracts to microservices without a rewrite, and it grades itself against a 34-category architecture rubric in the open. This series teaches it one pattern at a time: the failure mode each pattern fixes, the real type and ADR behind the MMCA.Common implementation, the honest trade-offs, and how to apply the idea even if you never install the package.

Each article stands on its own if you land on it from a search. This page is the index that ties them together: 52 deep-dives plus this map, 53 articles in all. The groups below run roughly from "why this exists" to "how to build with it," so reading top to bottom is a reasonable curriculum, but every link is also a fine place to start.

Start here

The thesis and the framing. Read these first if you have not met the framework.

Core patterns

The day-one building blocks. Error handling, the domain model, query intent, the handler pipeline, the reliability backbone that ties them together, the compensating handlers that undo a step no transaction can roll back, and the durable queue that runs an ordinary command later.

Data and persistence

How the data layer is built so a module owns its own database, and even its own storage engine, and can become its own service later without a rewrite.

Auth, the API edge, and cross-cutting

The concerns that sit across every module: authentication between services, authorization (by role, by permission, and by row ownership), password storage, safe retries, caching, error contracts, notifications, DTO mapping, browser session auth, the generic REST surface, defending the edge, encrypting PII columns at rest, the hardened response headers every host stamps, and the optional second factor, email-confirmation gate and stored permission grants that complete the identity story.

Run, extract, and harden

Bring the whole stack up with one command, then cut a module out into its own service, make the running system survive failure, see what it is doing in production, and put bounds, guardrails and token metering around the model call. Read these in order: Aspire first, then extraction, then resilience, then observability, then the governed LLM boundary.

Proof, front end, and getting started

The evidence that the patterns hold (fitness functions, the test pyramid, the erasure pathway), the reusable Blazor UI framework and the internationalization and theming that ride on it, the hands-on path from dotnet new mmca-app to your first module, your first fitness test, and the two real apps that run on all of it, the device-capability layer that lets one Blazor UI run in a browser and inside a native phone app, and two later additions that round out the framework surface: managed file storage with untrusted-upload handling, and provable HTTP API versioning.

Where to go next

If you are evaluating the framework, read 01 then 03 then 41: the thesis, the rubric, and the proof. If you are here to solve a specific problem, the core-patterns and cross-cutting groups are the toolbox. If you want to build, start at 39: it scaffolds the whole solution in one command, then explains what you were handed. Then 40, to make the conventions fail the build.

Previous: Article 52, "Finishing Identity: Second Factor, Email Confirmation and Stored Permission Grants." This index is article 53 of 53, the last one in the series, so it has no next.

MMCA.Common is Apache-2.0 licensed and open source. Star the repo, read the scorecard (the gaps are the honest part), or dotnet add package MMCA.Common.API and tell me what breaks. New patterns land regularly, then monthly evergreen.

Tags: .NET, Software Architecture, C Sharp, Microservices, Programming

← Back to The MMCA.Common series