DDD(Domain Driven Design)란

객체 지향에서부터

객체 지향에서의 핵심은 실세계의 객체들이 서로간의 상호작용을 바탕으로 책임, 협력, 역할의 관점을 가지고 메시지를 교환하는 것입니다. 즉 객체지향에서의 핵심은 결국 객체(무언가를 만드는 주체)입니다.

객체들을 어떻게 하면 추출할 수 있을까요?
어떤 객체가 필요한지 어떻게 알 수 있을까요?
객체들은 어떻게 해야 상호작용할 수 있을까요?

위의 질문들을 해결할 수 있는 방법이 바로 DDD(도메인 주도 설계)입니다.

도메인이란

도메인의 사전적 의미는 '정보와 활동의 영역'을 말하며, DDD에서는 어플리케이션 내의 로직들이 관여하는 정보와 활동의 영역이라고 받아들여 집니다.

DDD의 개념

DDD란 도메인을 중심으로 설계해 나가는 것을 의미합니다.

도메인이란 실세계에서 사건이 발생하는 집합입니다. 옷 쇼핑몰을 예로 들어보겠습니다.
옷 쇼핑몰에서는 손님들이 주문하는 도메인(Order Domain)이 있을 수 있고,
점주 입장에서 옷들을 관리하는 도메인(Manage Domain)이 있을 수 있고,
쇼핑몰 입장에서 월세, 관리비 등 건물에 대한 관리를 담당하는 도메인(Building Domain)이 있을 수 있습니다.

이러한 여러가지 도메인들이 서로 상호작용하며, 설계하는 것이 바로 DDD입니다.

DDD의 특징

DDD의 특징 중 하나는 같은 객체가 여러 개 존재할 수 있다는 것입니다.

주문 도메인에서의 옷은 손님들에게 팔기 위한 객체 정보들을 담고 있지만,
옷을 관리하는 도메인에서는 옷은 점주 입장에서 관리하기 위한 객체 정보들을 위주로 담고 있습니다.

즉, 문맥에 따라 객체의 역할이 바뀐다는 것입니다.

DDD 아키텍처

PRESENTATION LAYER: 표현 영역 또는 UI 영역. 사용자의 요청을 받아 APPLICATION LAYER에 전달하고 쳐리 결과를 다시 사용자에게 보여주는 역할을 합니다.
APPLICATION LAYER: 응용 영억. 시스템이 사용자에게 제공해야 할 기능을 구현합니다.
DOMAIN LAYER: 도메인 영역. 도메인 모델을 구현합니다.
INFRASTRUCTURELAYER: 구현 기술에 대한 것을 다룹니다.

DDD의 기본 요소

Entity와 Value

Entity

식별자를 가지고 있습니다.
식별자는 Entity 객체마다 고유해서 각 Entity는 서로 다른 식별자를 가집니다.

Value

Value는 불변을 원칙으로 합니다.
의미를 명확하게 표현하거나 두 개 이상의 데이터가 개념적으로 하나인 경우 이용합니다.
식별자가 존재하지 않습니다.

Aggregate

관련 객체를 하나로 묶은 집합
Aggregate는 집합에 속한 객체들을 관리하는 Root Entity를 갖습니다.
Aggregate로 묶어서 바라보면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있습니다.
Aggregate에 속한 객체는 유사하거나 동일한 라이프사이클을 갖습니다.
한 Aggregate에 속한 객체는 다른 Aggregate에 속하지 않습니다.
각 Aggregate는 자기 자신을 관리할 뿐, 다른 Aggregate는 관리하지 않습니다.

Repository

Aggregate 단위로 도메인 객체를 저장하고 조회하는 기능을 정의합니다.
Aggregate를 구하는 Repository 메소드는 완전한 Aggregate를 제공해야 합니다.
Repository가 완전한 Aggregate를 제공하지 않으면, 필드나 값이 올바르지 않아 Aggregate의 기능을 실행하는 도중에 NullPointerException과 같은 문제가 발생합니다.

참고: https://huisam.tistory.com/entry/DDD
참고: https://ppiyo5.tistory.com/21

728x90

저작자표시 동일조건