Why I’m Finally Letting Go of the Repository Pattern
- Gerar link
- X
- Outros aplicativos
Why I’m Finally Letting Go of the Repository Pattern
(Yes, I was a fan once upon a time.)
What it promised:
🔹 A clean boundary between domain logic and the data model/db
🔹 Easier maintainability by hiding data access details
🔹 Flexible architecture: swap out the ORM or DB anytime
🔹 Horizontal layering: controllers → services → repositories → DB
What I experienced instead:
🔹 Mapping overhead everywhere: data model, domain model, DTOs, etc.
🔹 Rigid layering: feature logic split across too many folders and files
🔹 Orchestration fatigue: most ORMs (EF, Dapper) already solve common data issues
🔹 Slowed delivery: multiple abstractions for minimal real-world benefit
When it clicked:
Realizing typical line-of-business apps don’t need all this ceremony. Focusing on data flow (request → handler → data model/events → response) cuts out layers that don’t add value.
Where I’m heading:
✅ Feature slices: group logic, data, and business rules together
✅ Less friction: directly leverage ORMs without a middleman (its enough abstraction)
✅ Flexible structure: add classes or services only when the feature truly demands it
✅ Clearer data flow: see exactly how data moves from request to database
My question:
Are you still using repositories by default, or are you ready to simplify and let the data flow?
Let's see how this works in practice:
Take a vertical feature slice like "RegisterUser" as an example. This approach shows the clear request flow and necessary dependencies (such as DbContext and Outbox). Most importantly, it keeps all RegisterUser logic in one self-contained slice instead of spreading it across multiple layers.
Keep the things simple as possible.
Read my full article here: https://lnkd.in/eXSqqAba
(Yes, I was a fan once upon a time.)
What it promised:
🔹 A clean boundary between domain logic and the data model/db
🔹 Easier maintainability by hiding data access details
🔹 Flexible architecture: swap out the ORM or DB anytime
🔹 Horizontal layering: controllers → services → repositories → DB
What I experienced instead:
🔹 Mapping overhead everywhere: data model, domain model, DTOs, etc.
🔹 Rigid layering: feature logic split across too many folders and files
🔹 Orchestration fatigue: most ORMs (EF, Dapper) already solve common data issues
🔹 Slowed delivery: multiple abstractions for minimal real-world benefit
When it clicked:
Realizing typical line-of-business apps don’t need all this ceremony. Focusing on data flow (request → handler → data model/events → response) cuts out layers that don’t add value.
Where I’m heading:
✅ Feature slices: group logic, data, and business rules together
✅ Less friction: directly leverage ORMs without a middleman (its enough abstraction)
✅ Flexible structure: add classes or services only when the feature truly demands it
✅ Clearer data flow: see exactly how data moves from request to database
My question:
Are you still using repositories by default, or are you ready to simplify and let the data flow?
Let's see how this works in practice:
Take a vertical feature slice like "RegisterUser" as an example. This approach shows the clear request flow and necessary dependencies (such as DbContext and Outbox). Most importantly, it keeps all RegisterUser logic in one self-contained slice instead of spreading it across multiple layers.
Keep the things simple as possible.
Read my full article here: https://lnkd.in/eXSqqAba
- Gerar link
- X
- Outros aplicativos
Comentários
Postar um comentário