[DDD 아키텍처/잡담] 도메인 주도 설계를 왜 해야 할까?

ERD와 DDD의 관계

• ERD는 각 도메인간의 관계를 fk로 참조하고 관련되어 있는 테이블끼리 연관관계를 만든다.
• 이 관계를 기반으로 스프링에서는 자바 클래스와 JPA를 사용하여 불일치 패러다임을 해소한다.

하지만 여기서 문제점이 각 클래스간에 @ManyToOne, @OneToMany, @OneToOne으로 도메인간 종속관계가 모두 이어진다.
이 문제는 정합성, 일관성으로 이어진다. 만약 Order와 Product가 있고 M:N 관계일떄 중간테이블인 OrderItem이 있다고 생각해보자.
만약 OrderItem에서 수정이 이뤄진다면 이 테이블은 Product와 연관이 있을까?
JPA를 사용하고 엔티티중심으로 생각한다면 두 테이블이 모두 중간테이블과 연관되어 있기 때문에 영향을 미칠 수 있다. 예를 들어 Product에서 가격에 대해 수정이 이뤄졌다고 한다면 이전에 주문했던 제품들도 가격이 모두 바뀌어야 할까?
실제로 그런 일이 발생했다면 고객센터에 불이 났을 것이다.

그렇기에 OrderItem과 Product는 서로 영향을 끼칠 수 없으며 종속관계도 아닌 것이다.
이처럼 서로 영향을 미치지 않고, 미치지 않도록 해야하는 부분을 도메인별로 영역을 나누고 분리하는 것이 DDD의 원칙중 하나라고 생각한다.
다른 말로 도메인에서 다른 도메인에 대한 정보를 얻어야 할 때는 직접 서비스나 레포지터리로 들어가는게 아닌 도메인을 통해 들어가는 것이다.
각 도메인간의 의존성을 끊어서 응집도를 높이고 결합도를 낮춰야 한다는 것이다.

튜터님께서 강의해주신 내용을 기반으로 두 가지 개념이 있었다.
바운디드 컨텍스트 라는 개념과 애그리거트 라는 개념이다.
애그리거트보다 바운디드 컨텍스트가 더 큰 개념으로 도메인을 하나의 컨텍스트로 잡는 것이다.

예를 들어 주문- 주문 아이템, 상품 , 가게 - 가게주소 처럼 어떠한 종속관계를 갖는 테이블은 어떤 도메인의 시작점에서 연결되는 지점이므로 하나의 컨텍스트로 묶을 수 있는 것이다. 이 컨텍스트는 각각 독립적이어야 한다. 이 영역을 바운디드 컨텍스트라고 칭한다.

두 번째로 애그리거트는 애그리거트 루트라는 개념이 있다. 아까말한 도메인의 시작점이다. 주문-주문아이템에서 주문이 도메인의 첫 시작점이다. 그리고 이 도메인의 시작점에 영향을 받는, 종속성을 갖는 주문 아이템이란 도메인이 애그리거트루트의 애그리거트 속성이다.

이렇게 나눠진 영역에서 만약 다른 도메인의 정보를 가져와 저장했지만 정보가 변경되었다면 어떻게 해야 할까?
우리가 아는 Message Queue 방식을 이용해 정보를 구독한 다른 객체들에게 행동의 변화가 일어난다면 그것을 읽고 정보를 업데이트하는 방식으로 데이터의 변경이 진행된다.

그렇다면 처음 설계를 할 때 DDD 방식으로 설계를 해야 한다면 어떻게 진행할것인가?

1. 가장 큰 주요 도메인을 나눈다. (주문)
2. 도메인의 하위 개념들을 나열한다. (발송자, 주문자, 주문 아이템 등등)
3. 이 개념을 클래스로 변환한다.
4. 바운디드 컨텍스트별로 엔티티를 패키지단위로 나눈다.

• 여기서 MSA는 변경 사항을 Event로 받아오고 단순 조회는 Rest API로 통신한다.
• 모노리딕 아키텍처는 Rest APi, Service/Facade 패턴으로 통신한다.

앞으로 만들어봐야 이 개념들이 더 정확해질 것 같아 이전에 했던 프로젝트를 이 방식으로 패키지를 나누고 바꿔보면서 이전에 공부하고 싶었던 개념들을 다시 연습해 보려고 한다!