daebalprime
commented
3 years ago 378p의 언급하신 내용은 서비스 하나가 여러개의 DAO를 사용하는 것 자체를 문제삼고 있진 않습니다. 단일 책임 원칙 및 DI 설계가 제대로 되어있지 않아 데이터 접근 기술의 변화가 있음에도 불구하고 UserService 등을 수정해야 하는 결합도가 높은 경우가 나쁜 경우라고 설명하는 것 같습니다.
1번의 경우 대부분의 경우 지킬 수 없는 상황이 올 것 같습니다. 예를 들어, 외부 서비스와 연동된 계정(쇼핑 사이트에 L포인트, GS포인트 등등 연계되어 있는 경우)을 조회할 경우에는 어떻게 쪼개야 할까요?
말씀하신 2번의 경우에는 제가 생각하기엔 위임 패턴에 가까운 것 같고, 단점으로 말씀하신 것도 사실상 설계 미스기 때문에 일어나지 않아야 할 일입니다. 단일 책임 원칙을 지켜야 하는 '악취'나는 상황이라고 누군가 그랬던 것 같습니다.
이 내용은 미팅 때 다루었으면 좋겠습니다.
책 378p에서 서비스 하나가 여러 개의 DAO를 사용해야 하는 경우가 나쁜 사례로 나옵니다. 그럴 경우 해결할 수 있는 방법이 두 가지 생각이 났는데, 다른분들 생각은 어떤지 궁금합니다 👀
1) DAO별로 서비스를 쪼갠다.
=> 서비스 하나에 하나의 DAO에 접근할 수 있도록 합니다. => N개의 DAO에 접근하는 기능이 있을 경우 N개의 서비스를 사용해야 합니다.
장점: 서비스 하나에 하나의 책임을 가짐. 단점: 서비스 수가 많아짐. 서비스끼리의 의존 관계가 복잡해짐.
2) DAO에 접근하는 서비스와 접근하지 않아도 되는 서비스를 명확하게 분리
=> DAO에 접근할 때는 어차피 CRUD만 수행하니까 DAO별 CRUD 를 수행하는 서비스를 만들어 필요할 때마다 갖다 쓴다. => DAO에 변경 사항이 있을 때 DAO에 접근하는 서비스 하나만 변경하면 된다.
장점: 비즈니스 로직과 데이터가 분리된다. 단점: 1)보다 서비스 수가 더 늘어난다. DAO의 변경이 DAO 직접 접근하지 않는 서비스에 영향을 주지 않는지 보장하기 어렵다.