🍡 DDD 적용하기 - 1

지난 프로젝트에서 여러번 리팩토링을 거치며 아키텍처에 관한 관심이 높아졌다. DDD 책을 추천 받고 인터넷을 열심히 서핑하며 공부 중이다.

블로그에 내용들을 정리하며 복기하고, 이를 이번 캡스톤디자인 프로젝트에 적용하면서 연습하려고 한다. 프로젝트에 대해 간단히 귀뜸하자면, 자기소개서 첨삭 서비스이다.

---

0. DDD 개념 정리

Entity : 고유한 식별자를 갖는 객체, 도메인의 주요 클래스

DDD에서는 데이터를 담는 역할뿐만 아니라 기능을 제공하는 역할
ex) 자기소개서

Value : 도메인에서 개념적으로 하나인 객체

두 개 이상의 데이터가 하나의 개념인 경우에 해당
불변으로 구현되도록 권장
ex) 작성자 (작성자의 이름, 작성자의 이메일 등)

DIP : 저수준 모듈이 고수준 모듈에 의존하는 구조

객체지향설계 5원칙 SOLID 중 D에 해당
Dependancy Inversion Principle(의존 역전 원칙)으로, 고수준 모듈이 직접 저수준 모듈에 의존하는 대신 고수준 모듈인 인터페이스에 의존
저수준 모듈은 인터페이스를 상속 받아 실제 기능을 수행

Aggregate : 개별 객체 중 관련된 객체를 하나로 그룹화 해주는 것

ex) 자기소개서 회사 정보 + 질문 + 답변 == 자기소개서 Aggregate

---

일단 DDD를 공부하기 전에 기존에 하던대로 DB 설계와 ORM 작성을 마친 상태이다. 공부하며 확인한 내용에 맞추어 수정해보려고 한다.

1. Aggregate 단위로 객체 묶기

캡스톤디자인 프로젝트의 기존 DB다. 자기소개서 입력, 수정, 저장, 삭제, 분석 등의 기능만을 가진 백엔드에게는 비교적 간단한 서비스라 DB가 조그맣다.

지금까지 학습한 내용을 토대로 Aggregate 단위로 묶어 보았다.

회원 Aggregate

회원 데이터 User Entity
회원의 구매 여부(Plan)을 나타내는 PlanStatus Value

자기소개서 Aggregate

자기소개서 데이터 Form Entity
자기소개서 작성 중/완료 여부를 나타내는 FormStatus Value
자기소개서 항목과 답변을 나타내는 Question Value

회사 Aggregate

회사 데이터 Company Entity

면접 Aggregate

면접 데이터 Interview Entity
면접 질문의 분류를 나타내는 InterviewCategory Value

위와 같이 구성하기 전까지는, Question이 독립된 Entity라고 생각했었다. Aggregate 단위로 묶으려 생각하다 보니 자기소개서 항목에 대한 답변을 작성하기 전에, 자기소개서 폼 자체의 존재 여부나 유효성 검사 등이 필요하다는 사실을 깨닫게 되었다. 즉, Form에서 검사 이후 Question을 변경해주는 기능을 실행해야 하며 Question이 Value라고 생각하게 되었다.

반대로 Company의 경우 단순히 회사 이름만을 저장하는 Form의 한 컬럼으로 취급했는데, 그 개념 자체가 자기소개서에 종속되지도 않을 뿐더러 회사의 정보가 더 필요하게 되거나 '회사별 자기소개서', '회사별 면접' 등의 필터링 기능 등 확장성을 고려해 새로운 Entity 및 Aggregate로 분리하게 되었다.

2. Value 값 변경

Value 객체의 경우 불변인 상태로 구현되는 것이 권장되며, 특히 Setter 사용을 주의해야 하는데 그 이유는 다음과 같다.

1. Set 메소드가 여기저기서 사용되면 유지보수성이 떨어짐
2. Set 메소드를 통해 곧바로 Value 값을 변경하게 되면, 이전에 필요한 일련의 검증이 이루어지지 않아 위험함

이러한 이유로 외부에서 Value 값을 바꾸어줄 때는 아예 새로운 객체를 할당해서 자리를 바꾸어준다. 또 내부 상태의 변경은 Aggregate Root를 통해서만 이루어진다.

3. Aggregate Root

Aggregate Root는 Aggregate 전체의 일관성이 깨지지 않도록 관리해주는 Entity로, Aggregate 내 다른 값을 변경하는 기능을 포함한다. 이는 여러군데에서 로직이 반복되는 것을 방지해주기도 한다. 역할은 크게 다음과 같다.

1. 데이터 변경 전 상태 점검
2. 다른 객체의 기능 모듈을 호출하여 실행 위임

대개 한 Aggregate는 Entity를 하나만 가지는 경우가 많다고 한다.
예시의 자기소개서 Aggregate에서는 Form이 Aggregate Root에 해당한다.

보통은 트랜잭션의 단위가 한 Aggregate의 범위에 해당하는데, Aggregate가 적절하게 설정되지 않은 경우에는 해당 테이블들이 전부 잠기게 되어 동시에 처리할 수 있는 트랜잭션의 수가 현저히 줄어든다.

Repository도 한 Aggregate를 담당하도록 작성하는 것이 권장된다. Aggregate의 상태가 변경되면 원자적으로 반영이 되어야 하기 때문이다.

---

여기까지 리팩토링을 진행하였다.