How do you detect over-engineering in a .NET system, and how do you reverse it without a rewrite?

1. Why it happens

2. Modular monolith as a landing zone

Single deployable
├── Modules/Ordering    (public API: IOrderingModule, events)  own schema: ordering.*
├── Modules/Billing     (public API: IBillingModule, events)   own schema: billing.*
├── Modules/Catalogue   ...
└── Host (composition root)

• Boundaries stay explicit (module public APIs, owned schemas, in-process events).
• Network hops, distributed transactions, per-service pipelines disappear.
• Architecture tests stop modules reaching into each other's internals.
• A module can still be extracted into a service later if a real scaling or team need appears.

3. Merging a service into a module, step by step

1. Move the service's code into a module project behind the same contract (interface or in-process handler).
2. Route callers to the in-process implementation behind a feature flag; keep the HTTP endpoint temporarily.
3. Move its data into the module's schema (or keep the database and change connection ownership first).
4. Remove the network call path and the old deployment.
5. Repeat for the next service.

4. Finding dead configurability and code

• Search configuration across all environments for keys only ever at defaults.
• Use feature-usage telemetry or production coverage tools to find never-executed paths.
• IDE "unused member" analysis, dotnet format analyzers (IDE0051/IDE0052) for unused private members.

5. Avoiding the opposite failure

Simplification should keep the boundaries real change patterns need. Removing a payment port because "we only have one vendor" is wrong if a vendor change is on the roadmap; collapsing a module boundary between teams that genuinely change independently recreates coordination pain. Use change history and ownership, not aesthetics, to decide.

6. Communicating it

• Lead with outcomes the business cares about: lead time, incident rate, deploy time, onboarding time.
• Avoid blame: earlier decisions were often reasonable for earlier assumptions.
• Offer a reversible, incremental plan rather than a "big simplification project".

7. Try it yourself

1. Count files touched in your last five small feature PRs; find layers present in every one.
2. Remove one pass-through layer for one feature; compare the next change's diff.
3. List config keys and check which ever differ from defaults.
4. Map which services deploy together over the last 20 releases.
5. Write an ADR template that requires a problem statement for new layers or services.

// Before: four pass-through layers for one read.
// Controller -> IOrderAppService -> IOrderDomainService -> IOrderRepository -> DbContext
// Each layer: same arguments in, same DTO out, plus a mapper per hop.

// After: one endpoint, one query, with the real rule kept in the domain.
using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<ShopDb>(o => o.UseInMemoryDatabase("shop"));
var app = builder.Build();

app.MapGet("/customers/{id:int}/orders", async (int id, ShopDb db, CancellationToken ct) =>
    await db.Orders
        .Where(o => o.CustomerId == id)
        .OrderByDescending(o => o.PlacedAt)
        .Select(o => new { o.Id, o.Total, Overdue = o.DueDate < DateOnly.FromDateTime(DateTime.UtcNow) && !o.Paid })
        .ToListAsync(ct));

app.Run();

public sealed class Order
{
    public int Id { get; set; }
    public int CustomerId { get; set; }
    public decimal Total { get; set; }
    public DateTimeOffset PlacedAt { get; set; }
    public DateOnly DueDate { get; set; }
    public bool Paid { get; set; }
}

public sealed class ShopDb(DbContextOptions<ShopDb> options) : DbContext(options)
{
    public DbSet<Order> Orders => Set<Order>();
}

If the overdue rule is used elsewhere, move it to a named policy (see DRY) rather than reintroducing layers. Requires the Web SDK and Microsoft.EntityFrameworkCore.InMemory.