SQL Server implementation with Clean Architecture refactors

[Ans-Maliktech]

Hi @Gramli,

I referenced this repository as a baseline for a project I was working on and wanted to share the extended implementation.

While your repository provides a streamlined Minimal API example, I have refactored the concept into a production-focused solution. I migrated the data layer to persistent storage using SQL Server 2022 with Entity Framework Core 9 and restructured the backend into a decoupled Clean Architecture (Core, Infrastructure, API layers).

I also expanded the RBAC implementation to fully integrate with the Angular client for granular permission management.

If anyone checking the issues is looking for a version of this auth flow that uses a persistent SQL database and layered architecture, the implementation is available here: https://github.com/Ans-Maliktech/UserAuthentication.net

Thanks for the solid starting point.

Best, Ans Abdullah Malik

[Gramli]

Hi @Ans-Maliktech ,
thanks a lot for sharing your project and for referencing this repository — I really appreciate it.

I was curious, so I checked the biggest commit in your repo. If you’re interested, I have a couple of suggestions that might help make the structure more production-ready:

• Keep your Program.cs as clean and readable as possible.
  You can move the // 3. *** DATABASE INTEGRATION *** and // 4. *** MIGRATION & SEEDING *** sections into extension methods with descriptive names. It keeps the startup file minimal and easier to maintain.

• Result is already provided by the FluentResults library.
  Since the project references FluentResults, having your own Result type may be misleading or cause confusion for future contributors.

• Repositories, DbContext, and sometimes even entities should stay internal to the Infrastructure layer.
  They should be accessed through interfaces, and entities are typically mapped to DTOs or domain/business objects before leaving the layer.

• Avoid disabling warnings — resolve them instead.
  This helps keep the codebase clean and more maintainable in the long run.

• Be careful with excessive comments.
  In production applications, commenting every step of a program flow or algorithm can become problematic — when the code changes, comments often don’t, which leads to misunderstandings. It’s better to keep comments for intent, not for describing what the code already expresses.

Thanks again for contributing and for taking the time to explore this project!

Best regards.
Gramli

[Ans-Maliktech]

Hi @Gramli,

Thank you for the detailed feedback! I really appreciate you taking the time to review the code structure.

Your points regarding the Program.cs cleanliness and the architectural boundaries (keeping Infrastructure internal) are excellent. I also agree about the Result pattern redundancy; I will switch to using the library's native types to avoid confusion.

I am going to refactor the solution to address these five points (especially tightening the visibility of the Infrastructure layer and cleaning up the comments/warnings).

Thanks again for the mentorship. I'll update the repo with these improvements shortly.

Best regards, Ans Abdullah Malik

[Ans-Maliktech]

Hi @Gramli,

I'm happy to report that I've completed the full refactor based on your code review.

Summary of Changes:

Strict Architecture: Changed UserContext and all Repositories to internal. The API layer now relies exclusively on Interfaces and cannot bypass the abstraction layer.

Clean Startup: Refactored Program.cs by moving SQL and Migration logic into dedicated Infrastructure extension methods. It is now purely a high-level orchestration file.

Standardization: Removed the custom Result class and fully migrated to FluentResults.

Housekeeping: Resolved all compiler warnings (0 Errors, 0 Warnings).

You can review the updated implementation here: https://github.com/Ans-Maliktech/UserAuthentication.net

The codebase feels much more robust now. Thanks again for the mentorship, it was a great exercise in architectural boundaries!

Best, Ans Abdullah Malik

[Gramli]

Hi @Ans-Maliktech,
Just one more thing — after last commit the Infrastructure layer references Microsoft.AspNetCore.App. In Clean Architecture, Infrastructure should only depend on external resources (like databases or external services), not ASP.NET Core.

ASP.NET Core belongs in the presentation layer (the Auth.API project), and keeping that separation helps preserve clear architectural boundaries.

Best
Gramli

[Gramli]

Move this to Discussions