Domain Driven Design

wkdwoo·2022년 5월 24일
0

Domain Driven Design

목록 보기
1/1

소프트웨어의 본질은 기술이 아니라 현실의 문제를 해결하는 것이다.

현실의 문제(도메인)을 잘 파악하고 그 문제 해결이 code로서 잘 구현될 때 가장 이상적인 소프트웨어라고 할 수 있다.

하지만 도메인의 문제를 잘 아는 사람과, 그것을 코드로 구현하는 사람이 분리되어 일하는 경우가 대부분이고, 이러한 경우 의사소통하기 어려운 현실적인 문제점이 존재한다.

도메인 주도 디자인 (Domain Driven Design: DDD)은 이렇게 기존의 어플리케이션 설계가 비즈니스 도메인에 대한 이해가 부족했던 문제를 해결하기 위한 설계 방법으로, 도메인에서 IT로 일방향 소통구조를 탈피하여 도메인과 IT의 양방향 커뮤니케이션을 매우 중요시한다.

DDD는 좋은 서비스를 개발하기 위한 기본 요소인 Loose Coupling(느슨한 결합)과 High Cohesion(높은 응집도)를 만족시키기 위한 필수 개념을 포함하고 있다.

결국 도메인 내의 여러 업무 정의나 문제를 어떻게 모델로 잘 표현하고, 그것을 바탕으로 구현하기 쉽게 이해할 수 있는 구조로 정의되느냐가 DDD의 핵심이다.

DDD는 다음과 같은 특징을 갖는다.

특징

  1. 도메인 그 자체와 도메인 로직에 초점을 맞춘다.

    일반적으로 많이 사용하는 데이터 중심의 접근법을 탈피해서 순수한 도메인의 모델과 로직에 집중하는 것을 말한다.

  2. 보편적인(Ubiquitous) 언어를 사용한다.

    이로서 분석 작업과 설계 그리고 구현에 이르기까지 통일된 방식으로 커뮤니케이션이 가능해진다.

  3. 소프트웨어 엔티티와 도메인 컨셉을 가능한 가장 가까이 일치시킨다.

    분석 모델과 설계가 다르고 그것과 코드가 다른 구조가 아니라 도메인 모델부터 코드까지 항상함께 움직이는 구조의 모델을 지향한다.


Ubiquitoius Language (보편 언어)

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

그리고 보편언어들로 정의할 때 고려되어야 할 사항은 Bounded Context(제한 영역) 범위 내에서 정의해야 한다는 것이다.


Bounded Context (바운디드 컨텍스트)

특정한 도메인 모델이 적용되는 제한된 영역 경계 내에선 동일한 모델을 일관되게 적용하는 것을 말한다.

예를 들어, ‘Sales’ 이라는 모델 및 용어를 정의할 때, Customer, product 등의 용어는 다른 context에서 다른 의미로 사용될 수 있다. 그렇지만 제한된 맥락(Bounded Context)인 Sales 에서 독립적으로 서비스 되는 것은 문제없는 범위로 여겨질 수 있다.

도메인 과 Bounded Context이 1:1 로 매칭되는 것이 가장 이상적이다.

Aggregate (애그리거트)

연관된 엔티티와 VO(Value Object)의 묶음, 일관성과 트랜잭션, 분산의 단위

관련 객체를 하나로 묶은 군집을 의미한다. 애그리거트로 묶어 바라보면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있다.

한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않으며, 대부분의 애그리거트는 한 개의 애그리거트를 가진다.

하위 개념을 표현한 모델을 하나로 묶어 제공해야 할 핵심 도메인 기능을 보유 하고 있는 모델을 Root Aggregate(루트 애그리거트)라고 하며, 루트 애그리거트를 중점으로 종속되어 있는 엔티티들은 동일한 라이프사이클(하나의 트랜잭션)을 가진다.

Domain (도메인)

일반적인 요구사항, 소프트웨어로 해결하고자 하는 문제 영역

Domain Model (도메인 모델)

특정 도메인을 개념적으로 표현한 것, 도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는 데 도움이 된다.

도메인 주도 설계 기본 요소


Entity(엔티티)와 Value(밸류)

도메인 모델은 크게 Entity(엔티티)Value(밸류)로 구분할 수 있다.

데이터와 함께 도메인 기능을 제공한다.

Entity (엔티티)

테이블 모델이며 식별자를 갖는다.

식별자는 엔티티 객체마다 고유하고, 각 엔티티는 서로 다른 식별자를 가진다.

Value Object(VO)

데이터 표현 모델. 식별자를 가지고 있지 않고, 불변을 원칙으로 한다.

의미를 명확하게 표현하거나 두 개 이상의 데이터가 개념적으로 하나인 경우 밸류 타입을 이용한다. 시스템이 성숙함에 따라 데이터 값을 객체로 대체한다.

VO의 값을 변경하는 방법은 새로운 VO를 할당하는 것 뿐이다.


Reference

DDD 핵심만 빠르게 이해하기 :: 온달의 해피클라우드(Happy@Cloud) (tistory.com)

DDD 중심 마이크로 서비스 설계 | Microsoft Docs

DDD(Domain Driven Design) - Incheol's TECH BLOG (gitbook.io)

DDD(Domain Driven Design) :: history (tistory.com)

카카오헤어샵의 DDD (brunch.co.kr)

도메인 주도 설계 (Domain-Driven Design) 개요::사이버이메지네이션 블로그 (tistory.com)

profile
그때는맞고지금은틀리다

0개의 댓글