DDD란 무엇일까?

최권민·2023년 3월 20일

CS DDD 스터디

CS스터디

목록 보기

2/8

이 글은 링크 및 다른 자료들을 참조 및 요약한 글입니다. 지식적인 한계로 인해 사실과는 다른 내용이 있을 수 있습니다. 해당 내용이 있다면, 언제든 알려주시면 감사하겠습니다.

목차
1. 마이크로 서비스
2. DDD

들어가며

기존에는 가볍게 DDD가 무엇인지를 다루고자 주제를 잡았지만, https://happycloud-lee.tistory.com/261?category=8322466 이 글을 보면서 생각보다 이 흐름이 조금 방대하지 않나 싶은 생각이 들었습니다.
이 글에서는 마이크로 서비스와 DDD만 다룰 예정이지만, 관심이 있다면 해당 링크에서 글을 읽어보실 것을 추천드립니다.
글에서 나온 핵심 요약입니다.

왜 일하는 방식이 변화 되고 있는지를 잘 나타내 줍니다.

마이크로서비스

마이크로 서비스를 검색하면 이렇게 정의합니다.
- 소프트웨어를 구축하기 위한 아키텍처이자 하나의 접근 방식으로, 애플리케이션을 상호 독립적인 최소 구성 요소로 분할합니다. 모든 요소를 하나의 애플리케이션에 구축하는 전통적인 모놀리식 접근 방식 대신 마이크로서비스에서는 모든 요소가 독립적이며 연동되어 동일한 태스크를 완수합니다. 이러한 각각의 구성 요소 또는 프로세스가 마이크로서비스입니다.
간단한 설명으로는 https://www.youtube.com/watch?v=ZRpsB3ODr6M 코딩애플에서 깔끔하게 정리해 두었습니다.

본 글에서는 마이크로서비스의 필요성을 '3S' 로 요약합니다.
- Speedy
  - 시장의 변화에 맞춰 남들보다 먼저 제품이나 서비스를 제공합니다.
- Scale
  - 필요한 수요에 맞는 서버를 구축합니다.
- Service Always
  - 서비스가 장애 없이 지속적으로 제공될 수 있도록 합니다.
이 세 가지를 제공하기 위해서 큰 서비스를 잘게 쪼갤 필요가 있습니다.
- 서비스가 작아지면 시장 변화에 대응하기도 쉽고, 각 서비스에 대한 서버 수를 증감시키는 게 직관적이게 됩니다.
또한 서비스를 잘게 쪼개는 것 뿐만 아니라 각 서비스 간 독립성도 유지시켜 주어야 합니다.
'3S'의 Speedy를 위해서는 서비스를 이터래이티브(Iterative)하게 만들 필요가 있습니다.
- 최소한의 기능만 갖춘 서비스를 빨리 출시한 뒤, 시장의 반응에 따라 서비스를 발전시켜 나가는 방식입니다.

그래서 필요한 것이 마이크로서비스 라는 수단입니다.
마이크로 서비스를 구현하기 위해 필요한 것은 다음과 같습니다.
- 첫째, 마이크로 서비스를 나누어서 설계하고 개발하는 방법론, DDD(Domain Driven Design) 입니다. 뒤에 자세히 설명하도록 하겠습니다.
- 둘째, 마이크로서비스를 개발, 배포, 운영할 수 있는 아키텍쳐인 MSA(Micro Service Architecture) 도 필요합니다.
- 셋째, 좋은 MSA와 마이크로 서비스를 만들기 위해선 MSA Features와 12Factors라는 특성과 요소들을 갖추어야 합니다.
- 12Factors 는 https://12factor.net/ko/ 를 참조하면 좋을 것 같습니다.
- 넷째, 큰 서비스가 마이크로화 되면서 생기는 문제들을 해결하기 위해서 '마이크로서비스 패턴'과 'MSA'의 다양한 기술들이 적용되어야 합니다.
  - 마이크로 서비스는 Complex, Consistency, Operational overhead, Performance 라는 4가지 큰 문제가 있습니다.
    - Complex는 마이크로 서비스의 개수가 많아지면 많아질수록 서로를 연결하고 통제하는 것이 복잡해진다는 의미입니다.
    - Consistency문제는 마이크로서비스는 자체의 데이터베이스를 갖게 되는데 그 데이터베이스들 간에 데이터 불일치가 발생할 수 있다는 것입니다.
    - Operational overhead 문제는 서비스가 나누어져 있어 운영을 위한 테스트, 배포, 버전관리, 장애 관리가 어렵다는 것입니다.
    - Performance 문제는 기존에 하나의 모닐리식(Monolithic) 서비스일 때는 불필요했던 서비스 간의 네트워크 트래픽이 발생하기 때문에 필연적으로 성능이 감소할 수 밖에 없다는 것입니다.
위의 내용을 요약한 사진은 다음과 같습니다.

DDD란?

1. 도메인이란?

사전적 의미는 '영역' 혹은 '집합' 입니다.
DDD에서 말하는 Domain은 비즈니스 Domain 입니다.
비즈니스 Domain은 유사한 업무의 집합입니다. (MPRS-마케팅, 구매, 연구, 영업)
어플리케이션은 비즈니스 Domain별로 나누어 설계 및 개발될 수 있습니다.

2. DDD(Domain Driven Design)란?

비즈니스 Domain 별로 나누어 설계하는 방식입니다.
- 기존의 어플리케이션 설계가 비즈니스 Domain에 대한 이해가 부족한 상태에서 설계 및 개발되었다는 반성에서 출발하였습니다. DDD에서는 기존의 현업에서 IT로의 일방향 소통구조를 탈피하여 현업과 IT의 쌍방향 커뮤니케이션을 매우 중요하게 생각합니다.
DDD의 핵심 목표는 "Loosly coupling", "High cohesion" 입니다.
- 어플리케이션 또는 그 안의 모듈 간의 의존성은 최소화하고 응집성은 최대화하는 것을 뜻합니다.
  - 정보처리기사 등을 공부하면서 모듈의 결합도와 응집도를 배우는데, 이를 생각하시면 될 것 같습니다.
  - https://m.blog.naver.com/gluestuck/221899977072
DDD는 Strategic Design과 Tactical Design으로 나눌 수 있습니다.
- Strategic Design은 개념 설계이고
- Tactical Design은 프로그래밍하기 위핸 구체적 설계라고 할 수 있습니다.

3. Strategic Design(개념 설계)

Business Domain의 상황(Context, 대상 사용자, 상황)에 맞게 설계하자는 컨셉입니다.
전략적 설계를 위해 Business Domain의 상황(Context)을 Event storming으로 공유하고, 비즈니스 목적별로 서비스들을 그룹핑합니다.
- 이벤트 스토밍은 여러 가지 색의 메모지에 자신이 생각하는 중요 이벤트, 사용자, 명령과 비즈니스 규칙을 적어 벽에 붙이면서 진행하는 워크숍입니다.
- 메모지를 벽에 붙이면서 곳곳에서 스몰톡이 일어나고, 그것을 토대로 구성원들이 도메인을 학습하는 것이 목적입니다.
- 이러한 이벤트 스토밍은 https://velog.io/@dnflekf2748/DDDDomain-Driven-Design 에서 진행을 잘 보여주고 있습니다.
( 카카오에서 DDD를 진행할 때 했던 이벤트 스토밍의 흔적입니다. https://tech.kakao.com/2022/12/12/ddd-of-recommender-team/)
Bounded Context & Domain Model
- 도메인 모델들을 나누어 컨텍스트 경계를 분명히 하는 것을 바운디드 컨텍스트라고 합니다.
- Bounded Context는 Biz Domain의 사용자, 프로세스, 정책/규정 등을 고유한 비즈니스 목적별로 그룹핑한 것입니다. 사용자, 프로세스, 정책/규정들을 그 Biz Domain의 Context라고 말할 수 있으므로 Bounded Context는 Domain안의 서비스를 경계 지은 Context의 집합이라고 할 수 있습니다.
- Domain Model은 비즈니스 도메인의 서비스를 추상화한 설계도입니다. Domain을 Sub Domain으로 분해한것과 Bounded Context가 Domain Model입니다.
Bounded Context & Micro Service
- 1개의 Bounded Context는 최소한 1개 이상의 Micro Service로 구성됩니다.
- 그래서 이렇게 바운디드 컨텍스트로 분류하는 것은 MSA를 구성하는 데에도 큰 도움이 됩니다.
Context Map
- Bounded Context 간의 관계를 도식화한 Diagram 입니다.
  
  ( 원래는 각각의 데이터의 흐름도 적어줘야 하지만, 카카오에서 진행했던 DDD는 이런 느낌입니다. )
  
  ( 이런 예제가 더 이해하기 좋을 수도 있을 것 같습니다. )
Ubiquitous Language
- 현업 개발자, 디자이너 등 참여자들이 동일한 의미로 이해하는 언어입니다.
- 비즈니스 도메인에 따라 동음이의어가 많기 때문에 정확한 커뮤니케이션을 위해 공통 언어를 정의하고 사용해야 합니다.
- 위의 과정들을 통해서 유비쿼터스 언어를 구축합니다.
Strategic Design의 결과물 : Domain Model

위의 내용은 글로만 보면 어렵고, 흐름을 예시로 보는 게 이해가 더 잘 될 것 같습니다.
관련된 예제는 원글 https://happycloud-lee.tistory.com/94 를 참조해주세요.

++ 어그리게이트(Aggregate) 이해하기

한 단위로 취급 가능한 경계 내부의 도메인 객체로 한 개의 루트 엔티티와 기타 엔티티 + VO로 구성됩니다.
어그리게이트는 고유의 비즈니스 목적 수행을 위한 데이터 객체들의 집합입니다.
Aggregate의 규칙은 RPO가 있습니다.
- Root Only: Aggregate Root만 참조합니다. Aggregate 내부의 entity나 VO를 접근할 때 직접 접근하지 말고 Aggregate root를 통해서 하라는 것입니다.
  - 스프링에서 개발할 때, Entity를 직접 사용하지 않고 Dto를 통해 사용하는 것과 비슷하게 느껴집니다.
- Primary key : 참조는 Primary key 사용 : 다른 Aggregate를 참조할 때 객체 자체를 레퍼런스하지 말고 객체의 primary key로 참조하라.
  - 예시) Order는 Consumer 객체 자체를 참조하지 않고, consumerId값으로 Consumer aggregate를 참조함.
- One to One : 한 개의 트랜잭션은 한 개의 Aggregate만 Writing
  - RDBMS에서는 1:N이 될 수 있습니다.

4. Tactical Design(구체적 설계)

개발을 위한 구체적인 설계도입니다.
Model Driven Design
- Strategic Design에서 설계한 각 Sub Domain별 Domain Model(Context Map)을 중심으로 설계하는 것을 말합니다.
Layered Architecture
- Tactical Design시 목적별 계층으로 나누어 설계하는 것을 의미합니다.
- Presentation, Service, Domain, Data Layer로 나누는 것을 추천합니다.
  - MVC 모델과도 얼핏 비슷한 부분이 있는 것 같습니다.

Spring에서도 비슷하게 Layer의 목적에 맞게 3가지 어노테이션을 제공합니다.
- Presentation Layer -> @Controller, @RestController
- Service Layer, Domain Layer -> @Service
- Data Layer -> @Repository

Entity & Value Object(VO) : 식별성과 가변성으로 구별
- Entity는 각 record 간에 구별이 필요한 객체이고, VO는 각 record간 구별이 필요없는 객체입니다.
- Entity는 가변적(Mutable)이고, VO는 불변성(Immutable)을 가집니다.
- VO를 권고하는 이유는 속성 자체도 객체화하여 어플리케이션의 유연성을 높이자는 취지입니다. 따라서 속성이 또 다른 하위 속성들로 구성된다면 VO로 하라는 것입니다.
- 개발 시 Entity의 프라퍼티는 String과 같은 기본형이 아닌 VO객체로 하는 것이 좋습니다.

Aggregate & Factory
- Aggregate는 Entity들을 대표하는 추상화된 객체입니다. 유연한 어플리케이션 개발을 위해 Entity간에 직접 커뮤니케이션을 하지 않고 Aggregate간에만 커뮤니케이션하도록 설계합니다.
- Factory는 Aggregate의 생성 처리를 담당하는 객체입니다. 개발에 따라선 Entity의 생성을 담당할 수도 있습니다.
Repository
- Data access를 처리하는 객체입니다.
- Aggregate, Entity를 위해 데이터 CRUD를 담당합니다.
- 실제 구현시에는 ORM을 쓰는 것이 가장 이상적입니다.