ADR 001 Use EFCore In Application Layer

Title

Using Entity Framework Core Directly in the Application Layer

Status

Accepted

Context

In the context of implementing Clean Architecture, a decision needs to be made regarding the use of Entity Framework Core (EF Core) for data access. Specifically, whether to use EF Core directly in the Application layer or to abstract it away using patterns like Repository or Unit of Work.

Decision

We have decided to use Entity Framework Core directly in the Application layer of our Clean Architecture implementation.

Consequences:

Pros:

1. Simplicity: Simplifies the architecture by reducing the number of abstractions between application logic and data access.
2. Performance: Potentially improves performance due to fewer layers of abstraction.
3. Ease of Development: Allows developers to leverage the full capabilities of EF Core without adapting to custom abstractions.
4. Rapid Development: Speeds up the development process, especially in the early stages of the project.

Cons:

1. Tight Coupling: Creates tight coupling between application logic and data access technology, making it harder to switch ORMs or data access strategies in the future.
2. Testability: Makes unit testing more challenging, as mocking EF Core's DbContext or using an in-memory database may be required.
3. Separation of Concerns: Blurs the lines between application logic and data access, potentially violating the principle of separation of concerns.
4. Leakage of Data Access Concerns: Business logic may become intertwined with data access concerns, cluttering the Application layer.

Rationale:

The decision to use EF Core directly in the Application layer is driven by the desire for simplicity and rapid development in the early stages of the project. While there are trade-offs in terms of tight coupling and testability, these are deemed acceptable given the project's current scope and priorities.