DDD 란?

박정호·2023년 1월 16일
1

Development

목록 보기
2/3
post-thumbnail

🚀 Start

이번에도 역시 너무나도 많이 들어보고 많이 볼 수 있었던 단어가 있어서 그 단어에 대해 알아보려 한다. 특별한 기술을 아니지만 이에 대한 이론을 알고 개념을 잘 알고 파악한 사람을 우대한 다는 채용공고를 정말 많이 볼 수 있었다.

바로 그 것은 DDD이다.



⭐️ DDD란?

DDD란 Domain Driven Design의 약자로, 큰 규모의 비즈니스를 각 도메인 별로 나누어 설계하는 방법론이다.

이해하기 좋게 예를 들어 보자면, 만약 이커머스 서비스의 경우 다음과 같이 나눌 수 있다.

  • 결제
  • 주문
  • 배송
  • 고객관리
  • 인증

이처럼 DDD는 큰 규모의 서비스를 작은 비지니스 단위로 쪼개어 각 도메인 간의 응집도를 높이고 서로 다른 도메인끼리 느슨한 의존도를 가지게 된다. (출처)



👉 DDD ? MSA ?

이렇게만 보면 각각 독립적인 서비스를 연결한 구조인 MSA의 개념과 굉장히 유사해보인다.

MSA를 탄생시킨 DDD

예상했던대로 MSA는 DDD로부터 왔다고 한다. DDD의 핵심 요소인 Loose Coupling(느슨한 결합)High Cohesion(높은 응집)은 MSA를 설계할 때 꼭 기억해야 할 설계 원칙이다.

DDD는 MSA의 서비스를 식별할 수 있는 도구를 제공할 뿐 서비스의 올바른 식별을 보장하지는 않는다. 즉, DDD를 사용한다고 MSA를 완벽하게 적용할 수 있는 것은 아니다.

👉 BFF & MSA 란?



👉 DDD 특징

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

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


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

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


보편적인(ubiquitous) 언어의 사용

유비쿼터스 언어: 전략적 설계에서 비즈니스 전문가와 개발자가 비즈니스를 개념화하기 위해 사용하는 언어.

도메인에서 사용하는 용어를 코드에 반영하지 않으면 그 코드는 개발자에게 코드의 의미를 해석해야 하는 부담을 준다. 코드의 가독성을 높여서 코드를 분석하고 이해하는 시간을 절약, 용어가 정의 될 때마다 용어 사전에 이를 기록하고 명확하게 정의 함으로써 추후 또는 다른 사람들도 공통된 언어를 사용할 수 있도록 한다.

그러면 어플리케이션 모델을 발전시키고 새롭게 생기는 도메인 관련 이슈를 해결하기 위해 도메인 전문가와 끊임없이 협력할 수 있게 된다.

👉 유비쿼터스 언어(보편 언어)의 중요성



⛏ DDD의 설계

DDD는 전략적 설계(개념 설계)전술적 설계(구체적 설계)로 구분할 수 있다.

전략적 설계(개념 설계) ➡️ 설계(구체적 설계)



👉 전략적 설계

마이크로서비스를 식별하는 역할로, 복잡한 도메인의 경계를 상황(context)에 맞게 명확히 정의하는 과정으로, 이벤트 스토밍을 통한 도메인 중심의 큰 방향성을 정하게 된다.

도메인 전문가 및 기술팀이 함께 모여 유비쿼터스 언어를 통해 도메인 지식을 공유 및 이해하고 이를 기준으로 개념과 경계를 식별해 바운디드 컨텍스트(bounded context)로 정의하고 경계의 관계를 컨텍스트 맵(context map)으로 정의한다.


🌈 이벤트 스토밍 기법

  • 마이크로서비스를 도출하기 위한 시스템 안의 이벤트를 이해하는 도메인 전문가와 개발자들의 브레인스토밍 활동

  • 어떻게 하면 효과적인 설계를 하고, 어떻게하면 큰 도메인을 마이크로서비스로 분할하는 것을 쉽고 빠르게 할 수 있을까 등을 고민한다.


이벤트 스토밍 Flow

1️⃣ 도메인 이벤트 작성

도메인 이벤트란 시간흐름에 따른 시스템의 동작을 의미한다. 이벤트들의 발생 순서를 고려하여 배치하여 하며, 작성할 때는 명사, 과거시제로 기록한다.

  • 사용자가 이커머스 사이트에 접속후 물건을 구매하기까지의 과정을 도메이 이벤트화(Orange)

2️⃣ 외부 시스템 작성

이벤트 발생시 부가적으로 호출되거나 관련되어지는 레거시 시스템 또는 외부시스템을 명사형태로 명시한다.

  • 결제 이벤트에 따른 외부결제시스템, 알림 시스템이 있을 수 있으며, 배송 이벤트에 따른 택배배송 시스템이 있을 수 있다.(Pink)

3️⃣ Command 작성

이벤트를 발생시키는 커맨드를 동사 형태로 작성한다. 이는 개발자 입장에서 구현하게 되는 API가 된다.

  • 각각 이벤트가 발생할 수 있는 각각의 커멘드 작성.(Blue)

4️⃣ Hotspot 작성

궁금한사항이나, 좀 더 논의가 필요한 사항, 결정하기 힘든 사항에 대한 내용을 작성한다.

  • 재가입, 품절 등의 부가적인 이벤트가 발생할 수 있는 상황을 고려.(Purple)

5️⃣ Actor 작성

엑터는 사람이나 조직의 역할을 말하는 것으로, 비즈니스를 수행하는 구제적인 역할을 고려해서 명사형태로 작성한다.

  • 구매자, 판매자 (연한 Yellow)

6️⃣ Aggregate

애그리거트는 이벤트가 상태를 변경하는 요소의 묶음으로, 가장 작으 도메인 모델의 모듈 단위이다. 커맨드와 도메인 이벤트가 영향을 주는 데이터 요소로, 커맨드와 도메인이벤트 사이에 상단에 겹쳐서 작성한다.

  • 회원, 상품, 결제, 상품(진한 Yellow)
    (아래는 액터와 커맨드 사이에 붙여진 잘못된 예시)

7️⃣ Bounded Context 정의

Bounded Context는 액터, 애그리거트, 커맨드 등을 고려하여 목적별로 그룹핑한것을 말하며, Domain안의 서비스를 경계 지은 Context의 집합이라고 할 수 있다.

8️⃣ Context Mapping

호출 관계를 명확히 이해할 수 있도록 컨텍스트 다이어그램을 그린다. 이를 통해 바운디드 컨텍스트 간의 관계를 파악하고 동기적 호출방식, 비동기적 호출방식을 고려한 표현도 가능하다.

  • 동기적(실선): 항상 일관된 데이터필요, 컨텍스트간 의존도가 높음
  • 비동기적(점선): 결과적 일관성으로 처리가능한 관계

Event Storming Convention

💡 좋은 이벤트 스토밍 예시들
👉 도메인 지식 탐구를 위반 이벤트 스토밍(Event Storming) 요약
👉 [MSA] 이벤트 스토밍(Event storming)
👉 이벤트 스토밍을 통한 마이크로서비스 도출



👉 전술적 설계

전략적 설계를 통해 식별된 마이크로서비스의 내부를 상세하게 설계하는 것으로, 비즈니스의 고유한 활동을 정확하게 모델링하는 설계 패턴과 방법을 의미한다. 그리고 도메인 모델 및 모듈 등을 정의한다.


마이크로서비스 내부 구조 설계

헥사고날 아키텍처는 도메인 영역과 외부 기술 영역을 완벽하게 분리하기 위해서 필요한 구조.

  • 고유한 비지니스 개념을 표현하는 도메인 모델, UI, DB 등 기술을 분리하는 것.

  • 이후에 빠르게 변화하는 기술의 변경과 대체를 쉽고 빠르게 수행.


Domain Modeling

이론적으로 완성된 도메인을 기반으로, 소스코드로 구현하기 위한 세부사항을 정의하는 단계

  • Entity와 값 개체, 표준 타입을 식별하고 Aggregate을 식별하는 도메인 모델 설계
  • 서비스 인터페이스와 리포지토리 인터페이스를 정의하는 도메인 모듈 설계
  • 각 마이크로 서비스 동기/비동기 연동을 설계하는 마이크로서비스 설계

Layered Architecture

Domain Model에서 역할에 따라 모델을 Entity, Value Object, Service 등으로 분리했다면...

레이어별로 분리하면 User Interface, Application, Domain, Infrastructure로 구분할 수 있다. 이처럼 레이어를 분리해야만 다른 사람이 코드를 읽고 이해하기 쉽습니다.

  • User Interface는 사용자의 요청을 하위 레이어로 전달하는 역할

  • Application은 복잡한 비즈니스 로직을 처리하는 레이어.

  • Domain은 도메인에 대한 정보, 객체의 상태, 도메인의 비즈니스 로직을 제공하는 레이어

  • Infrastructure는 영속성을 구현하거나 외부와 통신하는 기능을 제공하는 레이어

각 레이어는 아래와 같이 하위 레이어를 의존합니다. User Interface는 모든 하위 레이어를 의존할 수 있고 반대로 Infrastructure는 다른 레이어를 의존하면 안된다

💡 자세히
👉 MSA 이론 정리(전술적설계)
👉 DDD Quickly (도메인 주도 설계, 전술적-전략적 설계)
👉 카카오헤어샵의 DDD



💡 Reference
👉 DDD와 MSA 기반으로 좋은 서비스 개발하기
👉 DDD(Domain-Driven-Design)

💡 좋은 참고영상
👉 [Backend] ㄷㄷㄷ: Domain Driven Design과 적용 사례공유 / if(kakao)dev2022
👉 도메인주도 개발 시작하기

profile
기록하여 기억하고, 계획하여 실천하자. will be a FE developer (HOME버튼을 클릭하여 Notion으로 놀러오세요!)

1개의 댓글

comment-user-thumbnail
2023년 11월 5일

좋은 글입니다 ~! 많이 배웠습니다

답글 달기