Separation of the Persistence Layer from Infrastructure

[ParsaMehdipour]

Hi there,

While reviewing the architecture of the project, I noticed that the persistence layer is currently integrated within the Infrastructure project. Although this approach can work for simpler applications, it may lead to a tighter coupling of concerns as the system evolves.

To improve modularity and maintainability, I suggest separating the persistence logic (e.g., DbContext, repository implementations, entity configurations) into its own dedicated project, such as ProjectName.Persistence. This separation would:

• Align with the principles of clean architecture by isolating infrastructure concerns from data access logic.
• Make it easier to swap or mock the persistence layer for testing purposes.
• Improve clarity by enforcing a clear boundary between data access and other infrastructure services (e.g., email, file storage, logging).

Let me know your thoughts on this. If the team agrees, I’m happy to help with the refactoring effort or propose a possible structure for the new project layout.

[giovanninocco]

Hi Parsa,

Thank you for taking the time to review the architecture and for your valuable feedback. I really appreciate you highlighting the potential coupling issue with the persistence layer.

I think your suggestion to separate it into a dedicated project like ProjectName.Persistence is excellent and aligns perfectly with our goals for a more maintainable and testable system.

I'm more than happy to apply the proposed suggestions and eager to start the refactoring effort. Please let me know your thoughts on the best way forward or if you have a proposed structure.

Thanks again!

Best,

Giovanni

[ParsaMehdipour]

Hi Giovanni,

Thanks again for your kind response — I really appreciate your openness to architectural improvements.

I’ve reviewed the current project structure under src/template, and it’s great to see how modular and organized things already are with clear boundaries like Domain, Application, and Infrastructure.

To build on this, I suggest introducing a new top-level project named Persistence (e.g., Template.Persistence) alongside the existing ones. This would allow us to isolate the persistence logic (such as EF Core DbContext, configurations, repository implementations, and migrations) from the broader Infrastructure project.

This change would:

• Make the Infrastructure layer more focused on cross-cutting concerns (e.g., messaging, email, etc.)
• Clearly reflect the architectural responsibility of each project
• Simplify testing and future changes to the persistence mechanism

Let me know your thoughts — happy to collaborate on a concrete migration plan or send over a draft structure if that’s helpful.

Best regards,
Parsa

[giovanninocco]

Hi Parsa,

Thanks for the detailed suggestion! I think introducing a dedicated Persistence project makes a lot of sense. It would definitely help in clarifying the responsibilities of each layer and streamline things down the line.

Please go ahead and fork the repository and apply a pull request with the suggested improvements. I'm looking forward to seeing how this takes shape.

Best regards,

Giovanni

[ParsaMehdipour]

Hi Giovanni,

Thank you so much for the positive feedback and encouragement!

I’m glad the proposal aligns with your architectural vision. I’ll go ahead and fork the repository, set up the new Persistence project, and begin refactoring the relevant components accordingly. I’ll make sure to keep everything well-organized and consistent with the existing project structure.

Once I have a solid foundation in place, I’ll submit a pull request for your review. Looking forward to your thoughts once it’s up!

Warm regards,
Parsa