Closed epicblues closed 2 years ago
저도 그렇게 생각했습니다! A서비스가 B서비스를 직접 호출하게 되면 의존하게 되어 강하게 결합된다고 생각했습니다.
저도 잘 모르지만 DDD에서는 Event 방식으로 해결하는 것으로 알고 있습니다.!
저도 매우 궁금합니다!! 이번 프로젝트를 하면서 일단 repository를 가져와서 구현하긴 했는데 이것이 맞는 방식일까? 라는 궁금증이 있었습니다. 서비스에서 다른 서비스를 통해 가져오는 것이 맞지 않을까? 라는 생각을 했는데 여기서는 잘못된 방향이라고 해서 혼란스럽네요... 또한, 서비스에서 도메인을 DTO로 변환하지 않고 그대로 반환해도 될까? 라는 생각도 드네요
호옥시 여기서 말한 서비스는 Domain Service
가 아닐까요?
DDD에서는 Domain Service를 고려할 수 있습니다. 흔히 Application Service와 착각하는 경우가 있지만, Application Service에서는 Domain Logic이 담겨서는 안되며, Application 관심사(트랜잭션, Persistence, messaging)만을 다루어야 합니다. 참고: https://tech.junhabaek.net/백엔드-서버-아키텍처-domain-layer2-객체지향-다시-생각하기-d1978d7ecac6#d907
DTO를 넘겨주는 것도 서비스 간 결합도를 낮추는 해결방안 중 하나라고 생각합니다. 이유는 도메인이 변경되었을 때, 도메인 전체가 아닌 선택적 정보인 DTO만을 넘겨주기 때문에 변경에 대한 사실을 다른 서비스에 숨길 수 있기 때문입니다. 이를 통해 서비스간 의존되는 부분을 도메인 전체에서 한정된 DTO만으로 줄일 수 있다고 생각합니다.
윗 레이어로 갈 수록 변경의 위험이 크기 때문에 타 서비스와의 관계를 컨트롤러에서 맺어주게 되면 오히려 위험하다고 생각됩니다.
저희가 이렇게 레이어를 분리해서 도메인을 관리하는 방식이
messaging
하고,Transaction
내에서Persistence
하는 형식으로 생각했습니다.서비스에 Transaction을 거는 이유는,
해당 서비스 밖에서 예측 불가능하게 데이터가 변경되는 점을 막기 위함도 있는데
타 도메인의 Repository를 바로 호출하여 가져다 쓴다면 저자가 말한 데이터가 불일치되는 결과
를 일으킬 수 있다고 생각됩니다.
page 29 마지막 문단
저는 이걸 보고 "주문 관리 시스템에서 OrderService가 사용자의 정보를 확인하려고 UserService를 호출한다." 는 예시가 생각났는데, 제가 생각한 예시가 맞을까요?
서비스 결합도를 낮추려면 어떤 해결책이 있을까요? 혹시 해결해보신 분 있으면 꿀팁 부탁드립니다! 제가 생각해본 해결책은 이렇습니다.