우아한 객체지향 [우아한테크세미나] 정리 4

😊개요

한창 프로젝트를 하며 스프링과 객체지향을 접하고 활용 했을 때, 의존성에 관한 고민을 매우 많이 했었다. 그러던 도중 유튜브에서 우아한 객체지향 by 조영호님의 세미나를 듣고, 그동안 프로젝트를 진행하면서 이게맞나? 라고 생각했던 실타래들이 하나하나 풀리게 되면서 입을 벌린 상태로 보며 정리했었던 적이 있다. 그때의 내용을 곱씹으면서 다시 정리 해보자고 생각했다.

 

🎈설계 개선하기

설계를 진화시키기 위한 출발점 코드 작성 후 의존성 관점에서 설계 검토

→ shop과 order에서 사이클이 발생한다.

 

🎈해결 1. 중간 객체를 이용한 의존성 사이클 끊기

어떻게 보면 DIP의 변형이라 볼 수 있다.

의존성을 끊고 장바구니에서도 OptionGroup과 Option을 활용할 수 있으므로 재사용성이 증가한다.

사이클을 끊는 방법중의 하나로 생각하면된다.

 

🎈객체 참조로 구현한 연관관계의 문제점

• 객체들이 다 연결되어있기 때문에 모든 것이 조회가 가능하다. 메모리에 있을 때는 큰 문제가 되지 않지만 ORM이나 DB매핑을 하는 순간부터 문제가 생긴다.
• 흔히 말하는 Lazy로딩이슈나 오픈세션inview도 연관관계에 관한문제이다.

• 위와같이 쿼리가 길게나가며 이를 어디까지 읽어야되는지 가이드가 없다.

객체 참조는 ORM이나 DB매핑으로 가는경우 많은 성능 이슈들을 일으키지만, 객체참조는 이를 잊어버리게 만든다.

객체가 단순히 필요하다고 해서 객체참조를 해버린다면 연관된 객체가 많아져 트랜잭션의 단위가 점점 커지게된다.

이 때 shop order delivery 순서로 업데이트 된다.

이 상황에서 중요한것은 각 도메인별로 상태변경의 빈도가 다르다. 이대로 로직이 더 추가된다면 롱트랜잭션에 락이걸릴 가능성이 생긴다.

→ 객체 참조가 과연 필요한 것인가?

객체 참조의 경우 결합중에 가장 큰 결합으로 차지하기 때문에 필요한경우 끊어 버려야한다.

Shop을 탐색하기 위해 결합도가 가장 높은 객체 참조를 하는 것은 조금 딥하다. 그러면 이 의존도를 낮출수 있는 방법은 없을까?

Repository를 통한 탐색을 한다면 의존도를 상당히 낮춰줄 수 있다.

🎈규칙

• 함께 생성되고 함께 삭제되는 객체들을 함께묶어라.
  • 트랜잭션안에 같이 변동되는 것을 같이 넣는다.
  • 도메인 관점에서 이런것을 같이 묶어라
• 도메인 제약사항을 공유하는 객체들을 함께 묶어라
• 가능하면 분리하라
  • 예를들어 장바구니와 장바구니 항목을 봤을 때, 두개의 변경주기는 다르다. 배달앱처럼 한 장바구니에 하나의 업소만 포함해야한다면 다른 이야기지만 일반적인 장바구니는 도메인 컨스트레인츠를 공유하지 않는다.

도메인 밖의 객체들은 다 떨어 뜨려 놓고 아이디만 참조하게 두는게 좋다.

위와 같이 떨어뜨리고나면 영속성 저장소도 도메인단위로 변경가능하다는 장점이 있다.

참고영상