// the find
kgrzybek/modular-monolith-with-ddd
Full Modular Monolith application with Domain-Driven Design approach.
A full .NET modular monolith reference application implementing DDD tactical patterns, CQRS, outbox/inbox, and event sourcing across four business modules (Meetings, Administration, Payments, UserAccess). It's aimed at mid-to-senior .NET developers who want a realistic, non-trivial example of these patterns working together rather than another toy CRUD app. The documentation is unusually thorough, including ADRs, C4 diagrams, and event storming outputs.
- Module boundaries are enforced architecturally: each module has its own IoC container, its own DB schema, and can only communicate with other modules via published integration events - not direct method calls or shared tables. This is the pattern actually described in theory, actually implemented.
- The decorator pipeline for cross-cutting concerns (logging, validation, unit of work) is clean and shows exactly how to apply it without a framework doing magic behind the scenes.
- Architecture decision log (ADRs) documents why choices were made, not just what was chosen. The 17 ADRs cover things like 'why allow commands to return results' which are real debates teams have.
- Testing coverage is multi-layered: domain unit tests using only public API, architecture tests using NetArchTest to enforce module boundaries at CI time, integration tests, and even mutation testing with Stryker - most example repos have none of this.
- The in-memory event bus means you can't actually run this in a multi-instance deployment without replacing a central piece of the architecture. There's no Kafka/RabbitMQ implementation provided, so teams will hit this wall the moment they try to scale out.
- Last meaningful code push was mid-2024 and it targets .NET 7/8 era patterns. It still uses Autofac for DI and IdentityServer 4 (now archived), which is a real liability for anyone trying to adopt this today - IdentityServer 4 is EOL and the migration path is non-trivial.
- The Resource Owner Password Grant authentication flow used here is explicitly discouraged in OAuth 2.1 and considered a legacy pattern. Someone learning from this will bake in a deprecated auth flow.
- Event sourcing is only partially implemented in one module (Payments) as a demonstration, not used consistently. This creates a misleading impression that you can mix event-sourced and non-event-sourced aggregates freely in the same codebase without significant operational complexity.