I remember the times when I was completely sold on the idea of the Repository pattern. I wrote about it, talked about it in meetups, and used it exten
SlashSlime
No Image
채널 이름 바꾸기
Category
Empty
Assignee
Empty
No Image
I remember the times when I was completely sold on the idea of the Repository pattern. I wrote about it, talked about it in meetups, and used it extensively in projects, especially when I was diving deep into Domain-Driven Design (DDD) and layered architectures. The core principle was always the same: keep the domain layer free of data concerns and push data interactions out to dedicated repositories. It sounded great in theory and worked well for a while in practice.
But along the way, I found myself spending more and more time mapping data between different layers — database entities to domain objects, domain objects to DTOs, and so on — without seeing much real value, especially for typical line-of-business applications. My “Aha!” moment came when I realized how much simpler things could be if I just cut out the middleman, so to speak.
