도메인 주도 설계란 무엇인가?

 혼자 토이 프로젝트로 쇼핑몰을 개발하며 Entity를 설계해보면서, 의문이 생겼다.

처음 의문이 생긴 부분은 왜 setter, getter를 사용하는 것을 지양하는지 였고, 검색을 하며 DDD에 대해 알 수 있었다.

이 후, 최범균님의 '도메인 주도 개발 시작하기'를 읽고 알게 된 점을 정리해 본다.

 도메인 주도 설계(DDD)는 무엇일까?

도메인 전문가와 소프트웨어 개발자 간의 커뮤니케이션 문제를 없애고 상호가 이해할 수 있고 모든 문서와 코드에 이르기까지 동일한 표현과 단어로 구성된 단일화된 언어체계를 구축해나가는 과정

쉽게 풀어보자면 도메인을 중심으로 시스템을 설계해 나가는 것을 의미한다.

 - getter, setter를 남발하지 말자

 - 불변 객체를 사용하자

 - 생성자를 적극적으로 사용하자

 - 도메인에 알맞은 단어를 찾자

 

계층 구조

아키텍쳐를 설계할 때 주로 다음과 같은 4가지 영역으로 나뉘어진다.

표현 - 응용 - 도메인 - 인프라스트럭쳐 (사진 생략)

 

DDD를 사용해 계층 구조를 구현한다면 각 영역의 역할은 다음과 같다.

 

- 표현 영역 : 사용자의 요청을 받아 응용 영역에 전달하고, 응용 영역의 처리 결과를 사용자에게 보여주는 역할

(Ex) 스프링 MVC 프레임워크

 

- 응용 영역 : 시스템이 사용자에게 제공해야 할 기능 구현

                    응용 서비스는 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임

 

- 도메인 영역 : 도메인 모델을 구현, 도메인의 핵심 로직 구현

 

- 인프라스트럭처 영역 : 구현 기술에 대한 것을 다룸

 

이 때, 도메인,응용,표현 영역은 구현 기술을 사용한 코드를 직접 만들지 않는다.

대신, 인프라스트럭처 영역에 의존하게 되는데 '테스트 어려움', '기능 확장의 어려움' 2가지 문제가 발생한다.

이를 해결하기 위한 방법으로 DIP가 있다.

 

DIP(의존 관계 역전)

고수준 모듈이 저수준 모듈에 의존하지 않고, 저수준 모듈이 고수준 모듈에 의존하도록 하는 것이다.

이는 인터페이스와 구현 클래스를 분리함으로서 주로 달성할 수 있다.

 - 고수준 모듈 : 의미있는 단일 기능을 제공하는 모듈

 - 저수준 모듈 : 하위 기능을 실제로 구현하는것

 

Entity, Value, Aggregate

쇼핑몰을 예시로

- Entity : 주문, 상품, 회원과 같은 도메인의 고유한 개념을 표현

- Value : 고유 식별자를 갖지 않는 객체, Address, Money 같은 타입

- Aggregate : Entity와 Value 객체를 하나로 묶은 것, 복잡한 도메인을 잘 이해할 수 있도록 도와준다.

                      함꼐 생성되는 구성요소는 한 에그리거트에 속하게 하는 것이 좋다.

                      함께 변경되는 빈도가 높은 객체는 한 애그리거트에 속하게 하는 것이 좋다.

                        ex) Order - 주문 Entity, 주문목록, 주문자 ~~

- Aggregate Root : Aggregate에 속한 모든 객체가 일관된 상태를 유지하도록 관리하는 주체

 

Transjaction

 하나의 Transjaction에서 하나의 Aggregate만 변경하는 것이 좋다.

 응용 서비스에서 수정하도록 구현, 다른 Aggregate까지 수정하는 것은 책임 범위를 넘는다.

 - 선점 잠금 / 비선점 잠금

   - 선점 잠금 : DB Lock을 거는 방법

   - 비선점 잠금 : version을 이용한 체크

 

Repository

 Repository의 경우, Aggregate Root 단위로 존재

 Domain model의 Persistence를 처리

 

CQRS

명령모델과 조회모델을 분리하는 패턴이다.

명령 모델은 상태를 변경하는 기능을 구현할 때 사용하고 조회 모델은 데이터를 조회하는 기능을 구현할 때 사용한다.

보통의 경우, 조회 기능이 많이 요청되기 때문에 트래픽이 높을 경우, 분리하는 것이 유리할 수 있다.

 

Bounded Context

모델의 경계를 결정, 한 개의 Bounded Context는 하나의 Model만을 가진다.

 

 

후기

처음에 가졌던 궁금한 점들을 콕콕 집어주듯이 풀 수 있었다. 그리고 객체 지향에 대해서, 다시 생각해 볼 수 있는 계기가 되었다.

작성한 내용 이외에도 Domain service를 구현, Event를 처리하는 법들이 책에 있었는데, 후에, 프로젝트를 진행해보면서 사용하고 작성하려고 한다. 그 때가 되면 좀 더 나은 구조에 대해 생각하고 설계 할 수 있길 바란다.