DbContext 자체가 unit of work 에 대한 추상 레이어라서, 우리는 이를 구현해서 사용합니다.
ApplicationDbContext : DbContext
만약, 데이터 베이스가 아니라, 파일에 저장하는 경우를 고려하면 IRepository 로 한번 더 추상화할 필요도 있겠지만, 대규모 프로젝트에서 데이터 베이스를 사용하지 않는다는 것은 상상할 수 없는 얘기죠.
자료의 저장소로 데이터 베이스가 언제나 전제된다면, DbContext를 IRepository로 감싸는 것은 추상에 대한 추상일 뿐으로, 불필요한 복잡성에 지나지 않습니다.
따라서, 제가 든 코드의 예에서 IRepository를 사용한 것은, DbContext를 사용하는 환경이라면, 불필요하게 복잡하게 설계한 오류입니다.
다만 인터페이스를 사용하면서 혼란을 느끼신다면, 아래의 글을 참고하시면 좋을 것 같습니다.
윗 글은 인터페이스를 누가 정의해야 하고, 누가 구현해야 하는 지를 설명하고 있습니다.
여기에서 "누가"는 시스템을 구성하는 레이어를 가리킬 수도 있고, 그 레이어를 책임지는 개발자를 가리킬 수 있습니다.
마지막으로,
클린 아키텍쳐는 어렵지 않고, 구현하고자 하는 시스템에 대해 많은 통찰을 주는 것 같습니다.
작성 순서를 UseCase 부터 작성해보는 건 어떨까요?
UseCase => Model
UseCase => UI (윈폼, 웹, …)
UseCase 가 사용하지 않는 서비스는 시스템에 필요가 없습니다.
UseCase 를 소비하는 다른 모듈은 UseCase 이상으로 뭔가를 더 할 필요도 없습니다.
그리고, UseCase를 Interface로 감싸는 복잡성은, 다른 댓글에서 설명했다시피, 다른 책임자와 협업할 때, 업무의 경계를 확실히 나눌 때 빼고는 스스로를 괴롭히는 것에 지나지 않을 수 있습니다.
시스템(에 대한 요구 사항)이 달라지면 UseCase도 달라져야 합니다.
반대로, UseCase가 달라진다는 것은 시스템이 변화 - 다른 프로그램이 된다는 것을 의미합니다.
즉, UseCase는 시스템 자체이기 때문에, 굳이 한 번 더 추상화를 할 필요가 없습니다. 이는 우리가 Model 객체를 인터페이스로 감싸지 않는 것과 동일합니다.