TIL 2024-01-30 도메인 간의 서비스 참조, 레포지토리 참조

가장 큰 이유

레포지토리를 그냥 쓴다는 것은 JPA를 쓰는 것 JPA의 추상화 수준만 가져간다 → DB딴을 직접 연결한다는 것 개발 난이도 낮아지고 편함 → 비즈니스 룰을 가져갈 수 없음

A - B 의존을 별로 안 함 B - C 를 의존

소규모에서는 레포지토리 딴 넣는게 편할 것이다. 대규모 일때 문제가 됨

상품 → 결제 도메인이 있다면 상품이 결제 완료로 바꾸고 싶어했을 때 상품 도메인에서 바로 결제완료 시켜버린다면 결제 도메인에서 작성 한 비즈니스 코드를 활용하지 않는게 되어버림.

내가 모든 도메인의 비즈니스 로직을 파악하고 있어서 이런 고민이 생겼던 것

모든 아키텍처는 신입을 기준으로 → 신입이 처음 개발할 때 우리 회자 비즈니스 로직을 무시하고 레포지토리에 바로 접근하려고 하면? 😡

요령을 피우면 스파게티 코드가 되기 시작 → 어느 곳에선 서비스 참조, 레포지토리 참조 이러면?

순환참조 → 내가 설계를 잘못했다 (사실상 체크드 에러)

진짜 해결하기 힘든 경우에는 Facade 패턴을 사용함! 실무에서는 이런 상황 방지하려고 자주 씀

3레이어 관점에서 봤을 때 약간 위배 되는 행위지만,, 쩔 수 없다 느낌

service 참조

• 순환 참조가 발생할 가능성이 있다.
• A라는 서비스에서 B라는 서비스를 불러올 때, B의 레포지토리에서 B의 서비스를 만들어줘야하는데 이 때, A서비스를 위한 B서비스가 만들어지는 게 아닌가 라는 생각을 해볼 수도 있다.
• 데이터가 분산되지 않고 관리하기 편할수있다.

Repository 참조

• service -> repo 라는 단방향 계층으로 순환 참조같은 상황을 걱정하지 않아도 된다.
• 여러 서비스에서 데이터를 쉽게 불러올수있어서 유연하다.
• 데이터를 가져오는 로직이 여러 서비스에 분산되어서 관리하기 어려울 수 있다.

 

https://www.inflearn.com/questions/355565/service%EC%99%80-controller%EC%9D%98-%EC%97%AD%ED%95%A0%EC%97%90-%EB%8C%80%ED%95%9C-%EC%A7%88%EB%AC%B8%EC%9D%B4-%EC%9E%88%EC%8A%B5%EB%8B%88%EB%8B%A4

service와 controller의 역할에 대한 질문이 있습니다. - 인프런

https://www.inflearn.com/questions/467300/repository%EC%99%80-service%EC%9D%98-%EB%A7%A4%ED%95%91-%EA%B4%80%EA%B3%84

repository와 service의 매핑 관계 - 인프런