우아한 객체지향 강의 메모 - 05

 

https://youtu.be/dJ5C4qRqAgA?t=3859 

 

객체 참조의 문제점 : 모든것을 참조 -> 다 쫒아가고 싶은 욕망

영구적인 결합체 -> 객체 참조 끊기

오더를 알면 -> 샵으로 찾아 갈 수 있어

방법 -> 객체 참조 (물리적인 강도 - 결압도가 굉장히 높은 방법)

약한 결합도 -> Repository를 통한 탐색

ShopId를 통한 탐색

Repository에 대한 인터페이스 -> 연관관계를 구현할 수 있는

뭐를 찾아!

파라미터를 -> 이 객체를 찾을 수 있도록 만듦

조회쪽이 깨지면서 깨짐

실제로 구현을 하게되면

-> 사용자에게 보여주기위한 연관관계를 덕지덕지 붙게됨

-> 비지니스 로직

어떤 객체들은 묶고,

결합도가 높은 친구들

굳이 필요 x

구분해서 해결해야 됨

-> 도메인에서 어떤 개념들을

어떤식으로 같이 처리해야되?

따로 처리해도 되!

트랜잭션안에 같이 변경되는 것을 넣어야되 -> 비즈니스!

도메인 관점에서 묶어주기

같이 생성이 되고 같이 사라지는 것 -> 하나의 단위로 묶어 줌

그렇지 않은 것은 끊어버리는게 좋음

도메인적으로 제약사항을 공유하는 객체들을 함께 묶어라

가능하면 분리하라

장바구니가 생성되는 시점과

장바구니에 넣는 시점의 라이프 사이클은 다름

장바구니와 장바구니 사이의 공유되는 컨스트럭트가 별로 없음

제약사항이 없을 때 공유하지 않은 것 -> 찢기

제약사항 -> 잇으면 묶어야 됨

(묶는 것은 룰은 없음 -> 상황(비지니스 룰)에 따라서 객체단위로 묶어 줘라)

메뉴 / 샵 (별도) / 주문 / 배송

그러면 객체 그룹끼리는

Id로 참조하면 됨 -> Repository로 참조 함

객체를 어디에서 끊어야 되고, 어떻게 묶어야되는지

일단 -> 끊고나면 트랜젝션 단위로 묶어줌

조회를 하는 단위 -> 객체를 한번에 로딩을 하거나 Lazy해도됨

퍼포먼스 한계가 있음

한계가 잡혀져 있음

어디까지 레이징 로딩을 할꺼야? -> 최소한 어디까지는 같이 읽거나 레파지토리를 통해 읽을까

일단 참조 없는 객체 그룹으로 나누면

영속성 저장소 변경 가능 -> 판단기준

 

 

이 다를 때 실제로

하나의 단위로 저장

 

하지만 끊고나면 -> 컴파일 에러 발생

 

1:20:00

짜르는 이상 --> 에러로 나옴

일단 객체를 참조하는것을 다른 곳으로 옮겨버림

-> Validation Logic 모으기 (컴파일러 에러 나오는 것들)

 

-> 벨리데이션 응집도

-> 낮은 응집도의 객체 / 응집도 높은것 : 한번에 변경되는 것

 

때로는 절차지향이 객체지향보다 좋다 -> 응집도를 높이기 위해

 

하나의 객체를 만들고 -> 로직을 몰아 넣어서 -> 절차적으로

 

 1:23:00

2번째 에러 -> 배달완료 될 떄

-> 수수료 추가 -> 컴파일러 에러 ->

도메인 로직이 순차적 실행 -> 어떤 객체가 바뀔 떄 변경의 순서의 전후 관계가 있음

 

2개의 객체 그룹 -> 이것을 바꿀 때 이것도 바꾸고 싶어

 

 

1:25:00

1. 절차지향 로직 

방법 : 로직들을 다 끌어다 넣음 -> 주문이 완료되었을 때 오더도 상태가 변화해야되고, shop도 바껴야 됨

-> 작업들이 한눈에 보임

클래스가 두개로 쪼개져 있므

 

1:12:40

2.

 

1:29:30

3. 도메인이벤트 퍼블리싱

잘게 찢어서 느슨하게 끊고 싶음 -> 이 로직간의 순서를 느슨하게 하고 싶어

 

싸이클 의존관계가 발생함

 

 

 

1:36:00 

패키지 의존성

 

패키지 의존성을 끊는 방법

1. 새로운 객체로 변환

2. 의존성 역전

3. 새로운 패키지를 추가