A .NET monolith has fat controllers, shared database access, and tightly coupled services. How would you improve it while features are still shipping?

Evolve a legacy architecture in safe slices

Improves architecture through protected behavior, incremental boundaries, and measurable delivery instead of a risky all-at-once rewrite.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

First I would add characterization and integration tests around the workflow's contract, including important database behavior. Then I would move business decisions out of the controller into one cohesive use case, make dependencies explicit, and isolate one external or persistence boundary. The route and response can remain stable. Each step should be deployable and small enough to review, with feature work using the improved path instead of creating a parallel architecture.

Full answer below

Practice focus

Incremental refactoring, characterization tests, seams, strangler changes, module boundaries, migrations, observability, and rewrite risk.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
I would not begin with a full rewrite or a new folder template. I would choose one painful, frequently changed workflow and improve its boundary while preserving observable behavior.
First I would add characterization and integration tests around the workflow's contract, including important database behavior. Then I would move business decisions out of the controller into one cohesive use case, make dependencies explicit, and isolate one external or persistence boundary. The route and response can remain stable. Each step should be deployable and small enough to review, with feature work using the improved path instead of creating a parallel architecture.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I prioritize by change frequency, defect rate, delivery friction, and operational risk. A facade can protect callers while internals move. Database changes use expand-and-contract migrations so old and new code remain compatible during rollout. I avoid a generic shared layer that lets the legacy and new designs couple again. Architecture tests can prevent new references across the boundary, while the team documents a few rules that reviewers can actually enforce.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Starting a complete rewrite without behavior coverage.
Moving files while keeping the same coupling.
Building a second architecture that never replaces the first.
Changing code and schema in one irreversible deployment.

A .NET monolith has fat controllers, shared database access, and tightly coupled services. How would you improve it while features are still shipping?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Tech stacks

Skill areas

Suggest an improvement