프로젝트를 진행하며, 엔티티 별 응집된프로젝트를 진행하며, 엔티티 별 결합도에 대한 불편함을 느꼈다.
예를 들어,
1. 엔티티 별 도메인으로 나누기
Order
User
Product
라는 엔티티가 존재하고 이 엔티티 별 도메인으로 나누었다.
2. 각각에 대한 서비스 추가하기
서비스 API들은 아래와 같다.
-주문하기
-주문 확인하기
-상품 조회하기
3. 하나의 서비스에 대한 요구사항 확인해보기
-주문하기
=> 주문하기 위해서는 유저를 확인해야한다.
=> 주문하면 상품 엔티티의 재고를 업데이트 해야한다.
=> 주문하면 유저를 확인해서 Order를 추가해주어야한다.
-유저 마이페이지
=> 유저는 자신의 주문을 확인할 수 있다.
=> 유저는 Order라는 엔티티를 조회한다.
4. 문제 상황 발생
A 팀원이 주문하기 API 코드를 작성하며, OrderRepository에 INSERT로직을 짜두었다.
B 팀원이 유저 마이페이지 API 코드를 작성하며, 그 INSERT 로직을 사용했다.
A 팀원이 INSERT 로직을 조금 수정하였다.
B 팀원의 코드에서 상당한 오류 발생
5. 문제 상황 분석
엔티티 별 모듈화가 결합도를 올리는 꼴이 되었다.
Order 엔티티를 사용하는 모듈의 사소한 변경이 그 엔티티에 결합된(사용하는) 전체적 모듈에 대한 수정을 일으켰다.
6. 내 해결 방안 생각
Order, User, Product라는 기본적인 DB와 매핑되는 Aggregate를 만들어두고
주문하기는 그 Aggregate들을 DI 받아 사용하는 아키텍처를 생각해보았다.
이러한 과정들을 고민하며, DDD 책에서 내가 생각한 것과 비슷한 모델이 있는 것을 발견했다.
때문에, DDD를 공부해보며 결합도와 응집도, SOLID 원칙에 대해 생각해보고자 한다.
