Modern ASP.NET Core uses a small hosting entry point, but a large application can still turn Program.cs into a wall of registrations and middleware. The solution is not to hide everything. It is to give each concern a named home.
The composition root
The composition root is where the application is assembled. It should answer a few high-value questions quickly:
- Which configuration sources are loaded?
- Which databases are registered?
- Which services exist?
- Which middleware runs, and in what order?
- Which routes are mapped?
- What happens before the host starts?
CDIS keeps those questions visible in Program.cs while delegating detail to focused extension classes.
What belongs in the entry point
The entry point is a good place for sequencing:
builder.Configuration.AddApplicationConfiguration(builder.Environment);
await builder.Configuration.LoadKeyVaultSecretsAsync();
var databaseSettings = builder.Configuration.ResolveDatabaseSettings();
builder.Services.AddApplicationDatabases(databaseSettings);
builder.Services.AddApplicationServices(...);
var app = builder.Build();
app.UseApplicationPipeline();
app.MapApplicationRoutes();
await app.InitializeDatabaseAsync();
await app.RunAsync(...);The exact details belong elsewhere, but the order remains visible.
Why this helps migration work
During migration, developers often need to compare old and new behaviour. A named extension such as AddApplicationServices or UseApplicationPipeline creates a stable place to inspect one concern without searching through unrelated startup code.
It also makes review easier. A change to authentication registration looks different from a change to database provider selection, even when both are part of application startup.
The danger of over-abstraction
Extension methods can hide too much. If a method registers ten unrelated systems, the abstraction becomes another maze. The useful boundary is a cohesive concern with a meaningful name and documentation about ordering or environment assumptions.
The test project should be able to override the composition where necessary, especially database connections and cookie settings.
The lesson
Readable startup is an architectural feature. It shortens onboarding time, reduces accidental ordering changes, and gives future migration work a map of the application rather than another monolithic file.