MSA 와 DDD (2) (DDD를 활용한 MSA)

HeoSeungYeon·2022년 3월 14일

💡 MSA와 DDD 시리즈에서는 다음과 같은 순으로 포스팅이 진행됩니다.
(1) 왜 내가 MSA와 DDD 에 관심을 갖게 되었을까?
(2) DDD를 활용한 MSA
(3) DDD엔 어떤 문제가? feat. CQRS
(4) 모놀리식와 MSA의 조합

A. DDD를 활용한 MSA

MSA(마이크로서비스 아키텍처)를 구축하기 위해 좋은 방법 중 하나는 DDD(도메인 주도 설계)이다.

참고 자료에 따르면 MSA를 구현하는 필수 개념들이 DDD에서 왔고, 그 중 Loose Coupling(느슨한 결합)과 High Cohesion(높은 응집)은 DDD에서의 좋은 서비스를 개발하기 위한 핵심 기본 요소 중 하나이다.

DDD와 MSA의 핵심 기본 요소

1️⃣ Loose Coupling(느슨한 결합도)

2️⃣ High Cohesion(높은 응집도)

DDD를 기반으로 한 MSA를 적용하면 위 그림과 같이 도메인 내부 마이크로 서비스와 도메인 외부 마이크로 서비스로 분류되게 된다.

도메인 내부 마이크로 서비스는 API 기반의 Sync Call, 내부 메서드 호출, DB 통신등을 수행할 것이고,

도메인 외부 마이크로 서비스는 Async Call(메세지 기반 통신) 등을 수행할 것이다.

결국 앞서 언급한 통신들의 비용 절감은 2가지 핵심 기본 요소를 준수했을 경우 이루어지게 되는데,

이를 위해 MSA의 기반이 되는 DDD 에 대해 알아보는 시간을 가져보자.

B. DDD ( Domain Driven Design )

What is Domain?

Domain 은 ‘영역', ‘집합'이라는 사전적 의미를 갖으며, DDD에선 비즈니스 영역에서 유사 업무의 집합 혹은 영역의 의미를 갖고 있다.

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

What is DDD?

DDD 는 ‘도메인 주도 개발’ 을 의미하며, 비즈니스 로직을 Domain 별로 나누어 애플리케이션을 설계하는 방법을 의미한다.

모놀리식과 같이 하나의 애플리케이션에 모든 도메인 영역의 비즈니스 로직을 담게 개발할 때, 비즈니스 Domain에 대한 이해가 부족하게 되는 단점을 극복하기 위해 나온 설계 방식이다.

Features of DDD

1️⃣ 도메인에 집중한 개발

흔히 개발자는 데이터 중심의 접근법을 통해 개발을 한다. DDD에선 도메인 모델과 도메인 로직 중심으로 개발을 진행한다.

2️⃣ 보편적(Ubiquitous) 언어 사용

하나의 애플리케이션을 개발하다보면 도메인 전문가와 소트프웨어 개발자 사이의 의사소통에 드는 시간적 비용이 많이 발생한다.

이를 줄이기 위해선 도메인 전문가가 소프트웨어 개발자에게 전달해주는 문서, 소프트웨어 개발자가 도메인 전문가에게 설명해주는 코드 를 최대한 일치시켜 해석하는 언어가 아닌 이해하는 언어로 소통하는 것이 중요하다.

3️⃣ SW 엔티티와 도메인 Concept 의 일치

도메인 전문가가 알고 있는 컨셉과 SW 개발자가 개발한 모델 및 로직이 서로 다른 구조로 이루어져 있으면 안된다.

물 흐르듯이 하나의 도메인(모델 및 로직)은 코드 내부의 도메인과 일치되어야 한다.

Process of DDD

1. 개요

DDD는 Strategic Design(전략적 설계)와 Tactical Design(전술적 설계)로 구분된다.

DDD의 프로세스를 쉽게 설명하자면,

‘프로젝트’를 하나의 전쟁이라고 생각했을 때,

큰 틀에서의 ‘전략'을 통해 설계를 진행하고,

그 ‘전략'을 기반으로 구체적인 설계를 하는 ‘전술'을 통해 ‘프로젝트’(전쟁)의 성공을 도모하는 프로세스를 갖는다.

‘업무를 식별' → 전략적 설계

‘서비스(MS)를 정의' → 전술적 설계

2. 요약

Strategic Design(전략적 설계) :

‘개념' 설계
비즈니스 도메인 분석
도메인

Tactical Design(전술적 설계) :

프로그래밍을 위한 구체적 설계

3. 전략적 설계와 전술적 설계

전략적 설계

전술적 설계

DDD에서 사용되는 용어

1️⃣ 유비쿼터스 언어(Ubiquitous Language)

도메인에서 사용하는 용어를 코드에 적용하여 코드의 가독성을 증가시켜 코드를 이해하는 시간을 절감시켜주는 언어

2️⃣ 도메인

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

3️⃣ 도메인 모델

특정 도메인을 개념적으로 표현한 것.
도메인 모델을 사용하면 여러 관계자들이 도메인을 동일한 모습으로 이해하고 공유할 수 있다.

4️⃣ 엔티티(Entity)

데이터베이스의 테이블을 객체 지향적으로 표현한 것.

5️⃣ 값 객체(Value Object)

도메인에서 한개 이상의 속성들을 묶어 특정 값을 나타내는 객체
아래 2개의 조건을 통해 객체지향적으로 VO를 활용 가능하다.
- equals&hashCode 재정의
- 불변 객체

6️⃣ 에그리게이트(Aggregate)

연관된 엔티티와 VO의 묶음,
일관성과 트랜잭션, 분산의 단위
루트 에그리게이트 : 에그리게이트가 제공해야 할 핵심 도메인 기능을 보유하고 있는 모델

7️⃣ Bounded Context

사용자, 프로세스, 정책/규정 등을 고유한 비즈니스 목적별로 그룹핑한 것.

8️⃣ Context Map

Bounded Context 간의 관계를 도식화한 다이어그램

이벤트 스토밍(Event-storming)

앞서 언급한 DDD의 프로세스 중 하나인 전략적 설계를 이행하는데 있어 가장 좋은 방법은 이벤트 스토밍(Event-Storming) 이다.

이벤트 스토밍(Event- Storming)은 DDD 설계를 가속화 시키기 위해 이벤트 중심으로 이해 관계자들이 모여 브레인 스토밍 (Brain Storming)을 하는 워크샵이다.

보통 포스트잇(Post-it)을 벽에 붙여나가며 도메인의 흐름을 정리하는 지도를 구성한다.

이벤트 스토밍의 목적

이벤트 스토밍의 목적은 도메인 지식을 공유함으로써 전체 비즈니스가 어떤 흐름을 갖는지 도식화하는 것이다.

이벤트 스토밍의 구성

1️⃣ 빅 픽쳐(Big picture)

빅 픽쳐 단계에서는 핫스팟, 외부 시스템, 사용자를 도출한다.

2️⃣ 프로세스 모델링(Process Modeling)

프로세스 모델링 단계에서는 정책, 커맨드, 리드 모델을 도출한다.

3️⃣ 소프트웨어 디자인(Software Design)

소프트웨어 디자인 단계에선 어그리게이트(Aggregates)를 도출한다.

이벤트 스토밍의 진행 과정

이벤트 스토밍의 진행 과정을 다음 그림을 통해 간략히 이해해보자.

도메인이벤트 도출

(비즈니스의 상태 변경) 도출

커맨드 도출

(이벤트를 트리거하는 커맨드) 도출

외부 시스템 도출

(커맨드 및 이벤트 발생 시 호출되는 시스템) 도출

엑터 도출

비즈니스를 수행하는 구체적인 역할(사람 or 조직) 도출

에그리게이트 도출

연관된 엔티티와 VO의 묶음(에그리게이트) 도출
커맨드와 이벤트가 영향을 주는 데이터 요소

컨텍스트 경계 정의

마이크로서비스 후보가 되는 컨텍스트 경계 도출

정책 도출

[이벤트] 할 때는 항상 [커맨드] 한다 의 규칙에 맞게 정책을 도출한다.

컨텍스트 매핑

컨텍스트 경계 간 관계를 통해 컨택스트 맵으로 표현.
이때 각 호출 관계의 방향 및 호출 방식(동기, 비동기)을 판단하여 작성
- 동기 호출 : 비즈니스 일관성이 실시간으로 만족해야하는 관계 → 의존도를 높임.
- 비동기 호출 : 결과적 일관성으로 충분한 관계 → 의존도를 낮춤.
  
  즉, 비동기 호출로 결합도를 낮추면 각 서비스의 확장 및 독립성, 탄력성이 강화될 것임.