[DDD란?] Domain Driven Design

먼저 지금 자바 스프링에 대해 다시 공부를 하고있다..

김영한님의 인강을 들으며 공부중인데

이제 공부한 내용을 써먹어야지 내것이 되는거지 듣는다고 다가 아니니깐...

 

그래서 wagwagt 프로젝트에 백엔드를 java spring 으로 만드려고하는데

아키텍쳐에 대해서도 공부를 해보고 싶었고

최근 DDD란 것도 채용 공고에 많이 보여서 알면 좋을 것 같다는 생각이 들었다!!

 

그래서 공부할겸 사이드프로젝트에 DDD를 적용하여 개발을 해보려고 한다!!

 

우선 DDD가 뭔지 알아보기 위해 유튜브에서 카카오 파트너 페이지 팀에서 발표한 DDD 발표를 듣고 정리해봤다.

그리고 좀 더 검색을 해서 참고한 내용을 정리해보려고 한다!

---

1. Domain Driven  Design 이란?

도메인 주도 설계를 이해하기 위해서는 객체지향을 먼저 이해할 필요가 있다고 한다.

객체란 무엇인가?

객체 : 무언가를 만드는 주체라고 볼 수 있다.

 

어떻게 하면 이 객체들을 추려내고,
어떤 객체가 필요한지 알고, 어떻게 해야 객체들이 서로 상호작용 할 수 있을까?

 

여러 방법이 있겠지만, 이것을 해결해줄 수 있는 것이 바로 도메인 주도 설계이다!

 

* 쉽게 말하면, 도메인을 중심으로 설계해 나가는 것!

이제 도메인이 뭔지 궁금할 것이다.

도메인은 실제 세계에서 사건이 발생하는 집합이라고 생각하면 쉽다.

 

보통 우리가 Domain Knowledge(배경지식)라고 쓰는 용어 들이 서로 상호작용하는 집합이라고 보면 될것 같다!

 

 

옷 쇼핑몰로 예시를 들어보자

옷 쇼핑몰에는 손님들이 주문하는 도메인 - 주문 도메인(Order Domain)이 있을 수 있고,
점주입장에서는 옷들을 관리하는 - 관리 도메인(Manage Domain)이 있을 수 있고,
쇼핑몰 입장에서는 월세, 관리비 등 건물에 대한 관리를 담당하는 - 건물 관리 도메인(Building Domain)이 있을 수 있다.

위처럼 여러 도메인들이 서로 상호작용 하도록 설계하는 것이 바로 도메인 주도 설계이다.

 

2. 왜 DDD를 사용해야하는지 알아보자!

• 도메인 모델의 적용 범위를 구현까지 확장하여 도메인 지식을 구현 코드에 반영
• 유비쿼터스 언어를 사용하여 도메인과 구현을 충분히 만족하는 모델을 만든다.
• 실제 코드로 구현 가능한 현실성 있는 도메인 모델 분석과 그것을 추상화하는 설계
• "설계 하라, 그 다음에 구축하라" 가 아니다.

카카오 파트너 페이지 개발 팀에서는 간단하게

"리소스를 유연하게 가동하기 위해" DDD를 채택했다고 한다!

 

 

3. DDD의 특징

- 도메인 그 자체와 도메인 로직에 초점을 맞춘다.
    (일반적으로 많이 사용하는 데이터 중심의 접근법을 탈피해서 순수한 도메인의 모델과 로직에 집중하는 것!)

- 유비쿼터스(보편적인) 언어의 사용.

    ( 도메인 전문가와 개발자 간의 커뮤니케이션 문제를 없애고 상호가 이해할 수 있고 모든 문서와 코드에 이르기까지 동        일한 표현과 단어로 구성된 단일화된 언어체계를 구축해나가는 과정을 말한다. 이로서 분석 작업과 설계 그리고 구현까      지 통일된 방식으로 소통 가능!)

- 소프트웨어 엔티티와 도메인 컨셉트를 가능한 가장 가까이 일치시키는 것.

   (분석 모델과 설계가 다르고 그것과 코드가 다른 구조가 아니라 도메인 모델부터 코드까지 항상 함께 움직이는 구조의         모델을 지향하는 것이 DDD의 핵심원리)

 

데이터 주도 설계는 또 뭐지?

데이터 주도 설계란 객체가 가져야 할 데이터에 초점을 두고 설계를 하는 방식을 일컫는다. 데이터 주도 설계 에서는 객체 자신이 포함하고 있는 데이터를 조작하는 데 필요한 행동을 정의한다.

 

public class Movie {
    private String title;
    private Duration runningTime;
    private Money fee;
    private List<DiscountCondition> discountConditions;

    private MovieType movieType;
    private Money discountAmount;
    private double discountPercent;

    // getter, setter..
}

 

설계 시 협력에 고민을 하지 않았기 때문에 과도한 접근자와 수정자가 탄생하게 된다. 이는 후에 객체가 어떤 곳에 사용될지 알 수가 없기 때문에 최대한 많은 접근자와 수정자를 만들게 된 것이다.

결과적으로 데이터 중심 설계는 외부에 대부분의 구현이 노출되기 때문에 캡슐화의 원칙을 위반하게 된다.

내부 구현이 퍼블릭 인터페이스에 노출 되며 이 때문에 다른 객체들과 강하게 결합되게 된다. 이로 인해 객체의 내부 구현이 변경될 때 이 인터페이스에 의존하는 모든 객체들이 함께 변경되므로 높은 결합도를 유지하게 된다.

 

[같은 객체가 여러개가 존재할 수 있음!]

주문 도메인에서의 옷은 손님들에게 팔기 위한 객체 정보(name, price .. etc)들을 담고 있지만,

옷을 관리하는 도메인에서는 옷은 점주 입장에서 관리하기 위한 객체 정보(madeTime, size, madeCountry ... etc)들을 위주로 담고 있다.

 

문맥에 따라 객체의 역할이 바뀐다는 것!

이것을 Bounded Context라고 부른다.

 

 

 

4. DDD 적용에 필요한 것들

Bounded Context - 범위를 구분해놓은 하위 도메인 개념

    Bounded Context에 따라서 모델드르이 역할은 완전히 달라지고 책임 또한 달라진다.

    그래서 이를 외부로 노출시키지 않고 private으로 내부에서만 알 수 있게 하는 것이다.

    이러한 관점에서 더 나아가 직접 서비스에 적용시킨 것이 바로 MS(Micro Service)이다.

    다시 말해서, 서로 다른 도메인 영역에 영향을 끼치기 위해서는 API로 호출해야 한다는 말

    즉, 각각의 도메인은 서로 철저히 분리되고, 높은 응집력과 낮은 결합도로 변경과 확장에 용이한 설계를 얻는다!

 

Context Map - 그 Bounded Context간의 관계를 나타냄

Aggregate - 데이터 변경단위, 라이프사이클 같은 것을 모아놓은 집

연관된 엔티티와 벨류 오브젝트의 묶음, 일관성과 트랜잭션, 분산의 단위

루트 레그리게이트 : 에그리게이트가 제공해야 할 핵심 도메인 기능을 보유 하고 있는 모델

 

이벤트 스토밍

도메인 전문가와 개발자가 같이 참여 하여 어떻게 전략적으로 설계를 효율적으로 할것인가에 대한 방법이다. 이벤트 스토밍은 서비스에 필요한 모든 사람들이 다같이 모여서 진행을 한다. 개발요소가 아닌 이벤트와 비즈니스 프로세스에 집중한다. 팀 구성원 전체가 서비스 이해도를 증가할 수 있고, 도메인 전문가도 이해의 폭을 다시 넓히고 새로운 통찰력을 얻을수 있다.

https://incheol-jung.gitbook.io/docs/q-and-a/architecture/ddd#msa

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

자세히 보기

DDD의 아키텍쳐들의 종류로는

Layered 아키텍쳐,Clean 아키텍쳐, Hexagonal 아키텍쳐가 있다.

 

Layered Architecture

1. User Interface - 어플리케이션이 연결되는 계층으로 인풋아우풋이 통신변환등을 담당
2. Application - 도메인 개체를 직접적으로 사용하면서 어떻게 사용할지를 정의하는 유스케이스를 실제로 구현
3. Domain - 비즈니스 룰 등의 도메인과 관련된 직접적인 기능과 그 객체를 이루는 도메인 계층
4. Infrastructure - Repository나 Persistance , 메세지 전송과 같은 기술적인 기능을 제공하는 계층

** 카카오 페이지 팀의 경우 비즈니스로직이 거대해지면서 어플리케이션 레이어가 오염되는 경우가 염려되어 제외

Clean Architecture

1. External Interface - 데이터베이스 웹 프론트엔드 프레임워크를 기반으로 한 UI 인터페이스
2. Interface Adapter - DB나 파일시스템같은 외부소스에 저장하거나 혹은 내부에 유스케이스를 위해 양방향으로 데이터 변환을 수행하는 커뮤니케이터 역할
3. Use Case - 핵심 비즈니스 로직이나 애플리케이션 로직으로 구성됨
4. Entity - 엔티티 또는 도메인으로 구성된 내부의 유효성 검사 혹은 모든 도메인에 적용되는 일반 논리를 가지는 도메인 계층

Hexagonal Architecture (Port & Adapter 아키텍쳐라고도 부름)

1. Port - 데이터를 안쪽에서 알맞게 변환해주는 커뮤니케이터 역할을 함
2. Adapter - 각 포트에 맞는 어뎁터에서 알맞게 구현만 해주면 어떤 유틸리티든 가져다 쓸 수 있음
3. Use Case - 핵심 비즈니스 로직이나 애플리케이션 로직으로 구성됨
4. Entity - 엔티티 또는 도메인으로 구성된 내부의 유효성 검사 혹은 모든 도메인에 적용되는 일반 논리를 가지는 도메인 계층

비즈니스로직이 표현로직이나 데이터 접근로직에 의존하지 않도록 하는 것이 가장 중요한 목표!!

 

카카오에서는 포트엔 어댑터라는 명확한 구현개념이 포함되어져 있기 때문에 헥사고날 아키텍쳐를 고름!

 

 

 

 

단점과 장점

단점

1. MSA에서 오는 단점은 별개로
   1. 복잡해진 개발 난이도
   2. 개발 난이도를 해결할 숙련도 필요
   3. 트랜젝션관리와 통합테스트의 어려움
   4. 배포에대한 복잡도 증가
2. 아키텍쳐 구현에서 생성되는 생각보다 많은 코드
   1. ex)mapper같이 도메인을 사용하기위해 별도로 구현되는 코드
3. 각 도메인에 대한 높은 이해 필요

장점

1. 보편적인 언어 사용에 따른 빠른 커뮤니케이션
2. 도메인간 관계가 복잡한 경우 큰 틀에서 정리가 가능 (aggregate 같은 것들은 사용하면서)
3. 도메인의 분리에 따른 유지보수에 대한 편의성
4. 새로운 기능 및 요구 사항에 대한 유연성
5. aggregate사용으로 인한 도메인 Encapulation(캡슐화)
6. 유스케이스나 포트 사용등으로 인한 Loose Coupling,도메인로직과 서비스로직을 필요한곳에 모아서 사용하였기 때문 High Cohension
7. Domain Logic의 분리로 Business Logic에 집중
8. 코드 가독성

 

 

이렇게 정리를 해보았습니다..

적용해보지않고 우선 이론만 이리저리 찾아보고 이해한대로 정리를 했는데

부족한부분이 매우 많을것입니다..

 

보시고 피드백과 첨언 해주시면 매우 감사하겠습니다!!!

 

 

📢참고

https://huisam.tistory.com/entry/DDD

DDD(Domain Driven Design) - 도메인 주도 설계란? 마이크로서비스의 관점에서

https://incheol-jung.gitbook.io/docs/q-and-a/architecture/ddd

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