How Should ASP.NET Core Applications Be Structured for Long-Term Enterprise Maintenance?

This is where many applications fail. The application works perfectly in year one. Then requirements grow. More developers join. Integrations increase. Business rules become complicated. Deployment frequency increases. And suddenly the codebase becomes difficult to change. The solution isn't simply: “Use Clean Architecture.” Architecture should be driven by business boundaries, dependencies, change frequency and operational requirements. A maintainable ASP.NET Core application should establish clear boundaries between concerns. A common enterprise structure might conceptually look like: Presentation/API ↓ Application / Use Cases ↓ Domain ↓ Infrastructure But the important part isn't the folder names. It's the dependency direction. For example: Domain Should contain business concepts and rules that shouldn't depend on ASP.NET Core, Entity Framework implementation details or external services. Application Defines use cases and orchestration. Examples: Create customer Process order Approve invoice Generate report Infrastructure Handles implementation details such as: EF Core SQL External APIs Messaging File storage Email providers API / Presentation Responsible for: HTTP concerns Authentication/authorization integration Request/response models Validation boundaries API versioning concerns But enterprise maintainability requires more than layering. You also need: Dependency Injection Configuration management Logging Observability Exception handling Authentication/Authorization Automated testing CI/CD Security scanning Database migration strategy Caching Messaging where appropriate And one of the biggest architectural mistakes is introducing abstraction simply because a design pattern says you should. For example: Controller → Service → Repository → Generic Repository → EF Core doesn't automatically mean the application is well designed. Abstractions should exist because they create a useful boundary. A better question is: “What is likely to change independently?” That answer should influence your architecture. For larger systems, I'd also evaluate whether the application should remain a modular monolith or move toward microservices. Microservices aren't automatically more maintainable. They introduce: Distributed transactions Network failures Deployment complexity Observability challenges Data ownership problems Infrastructure overhead For many enterprises, a well-designed modular monolith can be the better starting point. Good architecture is not about having more projects, more patterns or more services. It's about making the system easier to understand, test, change, deploy and operate over time.