우아한객체지향을 보고 남기는 액기스

• 1. 세팅된 환경

• 2. 연관관계 개선하기

• 2-1. 중간 객체를 이용한 의존성 사이클 끊기

• 2-2. 연관관계 끊기

• a. 문제점

• b. 문제의 예시

• 2-3. 해당 변화를 통해 생기는 사이드 이펙트 - 컴파일 에러

• 2-4. 해당 변화를 통해 생기는 사이드 이펙트 - 컴파일 에러

1. 세팅된 환경

1. 개념객체들을 뽑아낸다. 개념객체간의 라이프사이클, 간섭, 응집 등을 고민
2. 개념들을 바탕으로 테이블 설계
3. 라이프사이클만 같으면 연관관계, 그 외에는 id값만 저장 -> id를 통해 연관관계 설정

 

• 특정 로직에 대해 협력을 설계해보자
• 관계에는 방향성 필요, 관계의 방향 == 협력의 방향 == 의존성의 방향

• 일반적으로 객체 참조를 통해서 연관관계를 구현한다.
• 객체 참조는 방법, 연관관계 구현이다. 1:1 매핑 관계가 아님을 인지하자.

• 모든 참조에는 이유가 있어야 함.
• 객체 참조는 결합도가 가장 높은 의존성

 

 

2. 연관관계 개선하기

2-1. 중간 객체를 이용한 의존성 사이클 끊기

 

2-2. 연관관계 끊기

a. 문제점

• 객체 참조로 구현한 연관관계는 두 객체 사이의 결합도가 높아진다.
  • 이는 하나의 객체를 수정하게 되면 다른 객체도 수정이 필요함을 의미한다.
• 이로 인해 성능 문제도 발생할 수도 있다. 조회 범위가 명확하지 않기 때문이다. 이는 실제로 필자도 프로젝트해보면서 경험해봤다.
  • 흔히 Lazy loading이 발생하면서 성능문제가 발생한다.
• 트랜잭션 경계도 불명확해진다.

b. 문제의 예시

• 더 자세한 예시로 살펴보자
• 배달 완료 로직에 대해서 shop, order, delivery 객체의 협력이 필요하다.

 

• 도메인 제약사항을 공유하는 객체들을 함께 묶어라
• → 특정 객체가 변경될 때, 다른 객체가 굳이 변경될 필요가 없다면 연관관계를 끊자.
• 예를 들어, 장바구니와 장바구니에 들어갈 항목은 라이프사이클이 다르다 → 연관관계를 끊어야 함.
  • 하지만 배민의 경우에는 가게당 1개의 장바구니만 허용한다 → 도메인 제약사항을 공유하기에 연관관계로 묶음
  • 결국 비즈니스 로직에 맞춰 유연하게 판단하는 능력이 중요하다.

 

• Lazy loading을 사용하기에 묶는게 개발하긴 편하긴 하다. 따라서 적절히 잘 사용하는 것도 중요함.
• 같이 생성되고, 같이 삭제되고, 같이 수정되어야 해서 CasCade도 사용 가능해짐.

 

• 그룹간 구분이 되었으면 이 그룹이 결국 트랜잭션 단위이자 조회 경계이다.

 

2-3. 해당 변화를 통해 생기는 사이드 이펙트 - 컴파일 에러

 

2-4. 해당 변화를 통해 생기는 사이드 이펙트 - 컴파일 에러

• 2가지 해결방법이 있지만 현실적으로 절차지향 로직이 실현가능할 것 같다.
• 도메인 이벤트 퍼블리싱은 일단 가볍게 알아두기만 하자.