Seeking Insights: Working with Large Modular Monoliths in C# Over Time
Background-Brick-157 seeks community insight on handling large modular monolith solutions in C#, focusing on scalability, module organization, and team impact as these systems grow.
Seeking Insights: Long-Term Experience with Large Modular Monolith Codebases in C#
Posted by Background-Brick-157
Modular monolith architectures have become increasingly popular for their ability to split functionality into distinct, well-organized modules while staying within a single deployable unit. In most publicized examples and blog posts, development teams often limit themselves to two to four modules, with a few extra projects for shared libraries and a dedicated bootstrapper.
However, real-world solutions sometimes grow far beyond these examples. Some organizations may find their modular monoliths expanding to 50, 100, or more modules over time. This raises important architectural and organizational questions:
- Does the modular monolith remain manageable as it scales?
- How does the increasing module count affect developer experience and productivity?
- What communication patterns are most sustainable between large numbers of modules?
Most blog posts show module folders with their own internal structure (typically 3–4 .NET projects per module for things like domain, application service, and API layers). As the number of modules increases, so does the complexity of solution management, build processes, and inter-module dependencies.
Key Discussion Points
- Module Count: How do solutions with 50+ modules handle organization, code navigation, and performance?
- Internal Structure: Are there standard ways of structuring modules internally that help with scaling?
- Team Impact: Does the increased module count impact collaboration, onboarding, or deployment?
- Communication Patterns: What approaches work best for module interaction—direct references, event-driven communication, interfaces, or something else?
Call for Community Experiences
The author is seeking real-world insight from teams and developers who have worked with large, modular monoliths written in C#. Which patterns, tool choices, or philosophies have helped or hindered you? What would you recommend or avoid when solution size becomes substantial?
Please share your lessons learned, tips, and perspectives on working with large modular monoliths in practice.
This post appeared first on “Reddit DotNet”. Read the entire article here