Over the last few days, I sepent time refining architectural patterns in a modular .NET backend centered around payroll processing, approvals, and workflow-driven operations. One area I focused on heavily was aggregate design and state protection. Instead of exposing mutable collections directly from entities, aggregates internally manage their own state exposing read-only access externally. private readonly List _monthlyAllowance = new(); public IReadOnlyCollection This prevents external code from bypassing aggregate rules; employee.MonthlyAllowances.Add(...) while still allowing controlled state transitions through aggregate methods: public void AddMonthlyAllowance(MonthlyAllowance allowance) _monthlyAllowances.Add(allowance); } Another major refinement was moving workflow reactions out of aggregates and into domain event handlers. Rather than aggregates directly triggering notifications or workflows, aggregates simply raise business events. public void AddMonthlyAllowance(MonthlyAllowance allowance) AddDomainEvent(new MonthlyAllowanceSubmittedForApprovalDomainEvent(Id, allowance.Id, EmployeeName)); } The aggregate only represents business behavior. Reactions happen externally through handlers: public sealed class This separation dramatically reduces coupling and keeps aggregates focused on business invariants instead of orchestration concerns. I also revisited feature-based application organization. As systems scale, grouping code by business capability rather than technical type becomes significantly easier to maintain. Instead of: Application feature-oriented organization tends to scale better: Application Another area that improved domain clarity considerably was replacing primitive-heavy models with explicit value objects. Instead of: public int cYear; the model becomes much more expressive: public PayrollMonth PayrollMonth { get; } with validation centralized inside the value object itself: public sealed class PayrollMonth : ValueObject public PayrollMonth(int year, int month) { if (month 12) throw new DomainException( "Invalid payroll month."); Year = year; Month = month; } } Approval workflows were another interesting area. Instead of tightly coupling approvals to controllers or services, workflows are modeled through state transitions and domain events: allowance.Approve(); AddDomainEvent( This allows notifications, audit trails, projections, escalations, and future integrations to evolve independently without modifying aggregate behavior. I also spent time evaluating architectural tradeoffs between: in-process messaging and distributed messaging One thing that consistently becomes clear in larger backend systems is that many scalability and maintainability problems originate from coupling and boundary design long before infrastructure becomes the bottleneck. For modular monolith architectures in particular, using MediatR with domain events provides a clean middle ground: maintaining loose coupling and workflow flexibility without introducing distributed-system complexity too early. Current stack and concepts: .NET 8 • EF Core • MediatR • DDD • CQRS-style patterns • Modular Monolith Architecture • Event-Driven Workflows dotnet #csharp #softwarearchitecture #ddd #backend #cleanarchitecture #modularmonolith #mediatr #cqrs #enterprisesoftware