1. 분석 > Event Storming: DDD 를 쉽게하는 방법
• 기존의 유즈케이스나 클래스 다이어그
래밍 방식은 고객 인터뷰나 엔티티 구
조를 인지하는 방식과 다르게 별다른
사전 훈련된 지식과 도구 없이 진행할
수 있다.
• 진행과정은 참여자 워크숍 방식의 방
법론으로 결과는 스티키 노트를 벽에
붙힌 것으로 결과가 남으며, 오랜지색
스티키 노트들의 연결로 비즈니스 프
로세스가 도출되며 이들을 이후
BPMN과 UML 등으로 정재하여 전환
할 수 있다.
vs.
• 이벤트스토밍은 시스템에서 발생하는 이벤트를 중심 (Event-First) 으로 분석하는 기법으로 특히 Non-
blocking, Event-driven 한 MSA 기반 시스템을 분석에서 개발까지 필요한 도메인에 대한 탁월하게 빠
른 이해를 도모하는데 유리하다.
2. 분석 > 이벤트 스토밍 통한 도메인 모델 도출
• DDD 를 통한 서비스 분석의 과정중, Event First 한 방법은 서비스 분해를 위한 기반 주요 객체들을 도
출 할 수 있는 방법을 제공함
이벤트 도출
(Domain Event)
커맨드 도출
(Command)
결합물 도출
(Aggregate)
• 키 비즈니스 이벤트
• OrderPlaced
• OrderShipped
• 이벤트를 발생시키는 액션
• 데이터 모델
• 이벤트 발생의 출처
• ACID 의 묶음
• AddOrder
• ShipOrder
• Order
• Shipping
과정
이등
록됨
강의
가등
록됨
강사
가매
핑됨
수강
이신
청됨
강의
일정
변경
됨
강의
가 취
소됨
수강
승인
됨
지불
요청
됨
과정
정보
입력
강의
정보
입력
강사
매핑
수강
정보
등록
일정
변경
강의
취소
과정이
등록됨
강의가
등록됨
강사가
매핑됨
수강이
신청됨
강의일
정변경
됨
강의가
취소됨
수강승
인됨
지불요
청됨
수
강
승
인
과
정
정
보
입
력
강
의
정
보
입
력
강
사
매
핑
수
강
신
청
일
정
변
경
강
의
취
소
강의
가등
록됨
수강
이신
청됨
강의
일정
변경
됨
강의
가
취소
됨
수강
승인
됨
지불
요청
됨
강사
가매
핑됨
과정
이등
록됨
강
의
(Cla
zz)
과정
(Cou
rse)
수
강
(Enr
ollm
ent)
축
하
메
시
지
발
송강
사
달
력
에
추
가
취
소
안
내
메
일
발
송
변
경
안
내
메
일
발
송
일
정
추
가
일
정
이
추
가
됨
일
정
노
티
발
송
노
티
이
력
단계 핵심 내용 예시이벤트 스토밍 결과
3. 분석 > 이벤트 스토밍 통한 컨텍스트 맵 > 서비스간 연계 관계 도출
• DDD 를 통한 컨텍스트 맵 도출을 위해서는 각 이벤트들에 의한 후속 액션과 바운디드 컨텍스트를 도
출하므로서, 모듈 간의 관계성과 관심사 분리 범위를 도출할 수 있다
단계 핵심 내용 예시
정책 도출
(Policy)
• 이벤트에 따른 각 서브도메인별
관심사
• 이벤트에 따른 후속 액션
• 회원가입시 환
영 메일 발송
바운디드
컨텍스트
• 모듈(마이크로 서비스)별 연동
관계 표시
• 각 서브도메인 별 관계성 표시
컨텍스트 맵
• 동일한 문맥으로 효율적으로 업
무 용어의 범위
• 하나의 BC 는 하나이상의 어그
리게잇으로 구성
• 어그리게잇과 BC는 마이크로서
비스 분해 단위의 후보
수
강
승
인
과
정
정
보
입
력
강
의
정
보
입
력
강
사
매
핑
수
강
신
청
일
정
변
경
강
의
취
소
강의
가등
록됨
수강
이신
청됨
강의
일정
변경
됨
강의
가
취소
됨
수강
승인
됨
지불
요청
됨
강사
가매
핑됨
과정
이등
록됨
강
의
(Cla
zz)
과정
(Cou
rse)
수
강
(Enr
ollm
ent)
축
하
메
시
지
발
송
강
사
달
력
에
추
가
취
소
안
내
메
일
발
송
변
경
안
내
메
일
발
송
일
정
추
가
일
정
이
추
가
됨
일
정
노
티
발
송
노
티
이
력
수강승
인
과정정
보입력
강의정
보
입력
강사매
핑
수강신
청
일정변
경
강의취
소
강의가등록됨
수강이신청됨
강의일정변경됨
강의가 취소됨
수강승인됨
지불요청됨
강사가매핑됨
과정이등록됨
강의
(Clazz)
과정
(Course)
수강
(Enrollment)
축하메
시지발
송
강
사
달
력
에
추
가
취소
안내메
일 발
송
변경
안내메
일 발
송
일정이
추가됨
일정
메일로그
과정개발 강의수강관리 달력
U D
Customer/Supplier + Sync
Anti-corruption Layer + Mediator
일
정
추
가
Conformist + ChoreographyLegend:
마케팅
수
강
승
인
과
정
정
보
입
력
강
의
정
보
입
력강
사
매
핑
수
강
신
청
일
정
변
경
강
의
취
소
강의
가등
록됨 수강
이신
청됨
강의
일정
변경
됨
강의
가
취소
됨
수강
승인
됨
지불
요청
됨
강사
가매
핑됨과정
이등
록됨
강
의
(Cla
zz)
과정
(Co
urse)
수
강
(Enr
oll
me
nt)
축
하
메
시
지
발
송
강
사
달
력
에
추
가
취
소
안
내
메
일
발
송
변
경
안
내
메
일
발
송
일
정
추
가
일
정
이
추
가
됨
일
정
노
티
노
티
이
력
과
정
개
발
강의관리 달력
마케팅
수강관리
• 주문
• 배송
• 회원관리
• 주문과 배송의 관계
는 Upstream,
Downstram 이며,
Conformist 임
이벤트 스토밍 결과
4. 분석 > 이벤트 스토밍 통한 컨텍스트 맵 > 마이크로 서비스간의 서열과 역학관계
• DDD 를 통한 컨텍스트 맵 도출에서 서비스들의 서열을 나눌 필요가 있으며, 이를 통하여 API 관리 주
체의 연계 관계와 연동 방법을 설정할 수 있다.
1순위: Core Domain
조직의 핵심 역량. 해당 역량은 아웃소싱이 불가능
한 조직의 생존과 경쟁력 자체인 영역임
예) 쇼핑몰 시스템에서 주문, 카탈로그 서비스 등
2순위: Supportive Domain
기업의 핵심 경쟁력이 아닌, 직접 운영해도 좋지만
상황에 따라 아웃소싱 가능한. 시스템 리소스가 모
자라면 외부서비스를 빌려쓰는 것을 고려할만한
예) 재고관리, 배송, 회원관리 서비스 등
3순위: General Domain
SaaS 등을 사용하는게 더 저렴한, 기업 경쟁력과는
완전 무관한
예) 결재, 빌링 서비스 등
Core Domain 간 (높은 서열끼리) 에는 Shared-kernel
도 허용가능하다. 하지만, 중요도가 낮은 서비스를 위해
높은서열의 서비스가 인터페이스를 맞추는 경우는 없을
것이다.
카탈로그
(core)
배송 SaaS
(general, 외부서비스)
상품추천
(supportive)
conformist
Anti-corruption
주문
(core)
Shared-kernel
5. 설계 > 이벤트 스토밍 결과에서 구현 기술 연동
• DDD 를 통한 서비스 분석의 과정중, Event First 한 방법은 서비스 분해를 위한 기반 주요 객체들을 도
출 할 수 있는 방법을 제공함
요소 구현체
• 도메인 이벤트 클래스
미들웨어/프레임워크
• 카프카
• Rabbit MQ
• 서비스 객체
• 레포지토리 객체
• Spring Data REST
• RESTeasy
• 엔티티 클래스 (ORM) • JPA
이벤트
(Domain Event)
커맨드
(Command)
결합물
(Aggregate)
정책
(Policy)
바운디드
컨텍스트
• 엔티티 클래스의 Hook에
정책 호출 구문 주입
• CDC 를 통한 이벤트 후크
• 마이크로 서비스 (후보)
• JPA Lifecycle Hook
• CDC (Change Data Capturing)
• Spring Boot
6. 6
설계 > 서비스간 연동 방안
• 이벤트 스토밍의 결과를 서비스간의 연동 토폴로지와 트랜잭션 처리에 대한 설정의 기준으로 삼음
마이크로서비스간 트랜잭션의 묶음을 어떻게 할 것인가?
배송기사가 없다고 주문을 안받을 것인가?
상품 추천이 안된다고 주문버튼을 안보여줄 것인가?
Core Domain 간에는 강결합이 요구되는 경우가 생길 수 있다. 하지만 우선순위가
떨어지는 비즈니스 기능을 위해 강한 트랜잭션을 연결할 이유는 하등에 없다.
재고
(core)
배송
상품추천
(supportive)
UI mashup
Async
Event-driven
Eventual TX
주문
(core)
ACID TX
(2PC)
라이락 스티커 (Policy) 를 어디에 둘 것인가?
강
의
정
보
입
력
강
사
매
핑
일
정
변
경
강
의
취
소
강
의
가
등
록
됨
강
의
일
정
변
경
됨
강
의
가
취
소
됨
강
사
가
매
핑
됨
강
의
(Cl
az
z)
강
사
달
력
에
추
가
취
소
안
내
메
일
발
송
변경
안내
메일
발송
일
정
이
추
가
됨
일
정
메
일
로
그
강의관리 달력
강
의
정
보
입
력
강
사
매
핑
일
정
변
경
강
의
취
소
강
의
가
등
록
됨
강
의
일
정
변
경
됨
강
의
가
취
소
됨
강
사
가
매
핑
됨
강
의
(Cl
az
z)
일
정
이
추
가
됨
일
정
메
일
로
그
강의관리 달력
축
하
메
시
지
발
송
강
사
달
력
에
추
가
취
소
안
내
메
일
발
송
변
경
안
내
메
일
발
송
일
정
추
가
메
일
발
송
Orchestration Choreography
More autonomy to handle the
policy
Low-Coupling
Originator should know how to
handle the policy
Coupling is High
마케팅 마케팅
7. 설계 > 서비스 분리시 분리 전술
• 기존 모놀로식 서비스를 분리할때 발생할 수 있는 다양한 문제가 발생하며, 이를 위한 분리 전술들을
설계해야 함
Course
(Mongo DB)
Marketing
(File Sys)
Class
(H2)
SME
(RDB)
Calendar
(External)
강사
스케쥴
확인
(REST)
강사
스케쥴
등록
(Sub)
강의 일정 발생
(Pub)
MQ (Kafka)
광고
메일
발송
(Sub)
….
<<Entity>>
Cours
e
<<Entity>>
Clazz <<Entity>>
Instructor
<<Entity>>
Schedule
<<Entity>>
Notificatio
n
<<Entity>>
Enrollm
ent
<<Entity>>
YetAnother
…
REST API
API
Gateway
JPA
Service Object
Generated by
Spring
Repositories:
CourseRepository
ClazzRepository
InstructorRepository
H2
<<Entity>>
Course
<<Entity>>
Clazz
<<Entity>>
Instructor
<<Entity>>
Schedule
<<Entity>>
Notificat
ion
<<Entity>>
Enrollme
nt
REST API
강 결합된 객체
참조 구조
<<Entity>>
Topic
객체 참조 방안
• 참조해야 할 도메인 클래스들의 공통화
Shared Kernel, Maven Repo 등을 통한 공통
모델의 공유: 동일 언어인 경우 유리, 디펜던시 발
생
혹은 중복 모델 개발 : Polyglot 인 경우 유리
• Entity 분리에 따른 원격 객체 (어그리게잇) 참조
Primary Key 를 통해서만 참조
HATEOAS link 를 이용
API 통합 방안
• API Gateway
진입점의 통일
Path-based Routing (기존에 REST 로 된경우 가능)
• Service Registry
API Gateway 가 클러스터 내의 인스턴스를 찾아가는 맵
8. 8
설계 > 레가시 전환 – 스트랭글러 패턴
• Strangler 패턴으로 레가시의 모노리스 서비스가 마이크로서비스로 점진적 대체를 통한 Biz 임팩트 최소
화를 통한 구조적 변화
Strangler application
Service Service
Service
Service
Service
Service
Service
… Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Time
Monolith
Monolith
Monolith Monolith
… Monolith
The Monolith shrinks over time.
The strangler application
Grows larger over time.
• 기존에서 분리된 서비스 영역이 기존 모노리스와 연동 될 수
있도록 해주는 것이 필요.
• 그 방법은 앞서 동기/ 비동기 방식이 채용될 수 있음
• 동기 – 레거시로 하여금 기존 소스코드 수정 요인이 높음, 따라서
이벤트 기반 비동기 연동 (CQRS) 추천
Modified from Microservices Patterns, Chris Richardson, Manning, 2018
• CDC (Change Data Capturing) 기능 사용
DB 의 Change Log 를 Listening, Event 자동퍼블리시 하는 툴
Debezium, Eventuate Tram 등이 존재
레가시
시스템
New 서
비스
Event
pulisher
Event handler
Translation
layer
Messaging
client
Order
event
Event channel
Anti-corruption layer
Ubiquitous language of service
Ubiquitous language of monolith
9. 9
설계 > 데이터베이스 분리 > DB per Services
|5.MSAGoalsandDesignPatterns
• 방법 1: Db per svc, API 기반 데이터 참조:
• 기존 join sql 참조를 통한 외부데이터 참조를 모두
REST 방식으로 전환.
• 기존 코드 수정량이 막대함.
• 기존 레거시 전환시 비즈니스에 임팩트를 줄 수 있음
• 그린필드 프로젝트인 경우 (새로운 서비스) 추천
• ERP 같은 참조 데이터량이 많은 경우 구현자체가 불가능
할 수 있음
• 사용할 수 있는 플랫폼
• Composite Services
• GraphQL
REST
10. 10
설계 > 데이터베이스 분리 > Miniservices
|5.MSAGoalsandDesignPatterns
• Miniservices: 물리적 데이터베이스는 쪼개지 않
고 하나로 두면서 애플리케이션에서 데이터베이
스를 접근하는 권한만 나눔.
• Shared db, schema per service
• 테이블 관리 권한을 각 서비스 주체별로 분리
• 자치성을 제공
• 각 서비스별 다양한 데이터베이스 제품의 선택권은
포기
11. 11
설계 > 데이터베이스 분리 > ES, CQRS, Replication
|5.MSAGoalsandDesignPatterns
• Replication + db per svc:
각 서비스는 각자의 물리 db 로 완전 분리해주고 대신
각 서비스에서 상호 참조하는 테이블 내용을 복제해주
는 방법.
• 복제의 방법과 시점이 이때 중요한데 완전히 같은 포
맷의 테이블 구성의 참조용 테이블을 만들어 주기적으
로 동기화 하는 방법과 원천 데이터의 마이크로서비스
에서 변경이 생김과 동시에 이벤트로 퍼블리시 한 후
수신측 마이크로 서비스가 알아서 자기 입맛대로 이벤
트의 내용을 자신의 디비에 반영하는 방법이 있음.
• 이벤트 소싱, CQRS 기법으로 접근하는 최근에 추천하
는 방법으로 이 각 서비스는 각자의 polyglot 한 db 제
품과 테이블 설계 자율성을 가질 수 있는 가장 loose
coupled 한 데이터베이스 설계.
12. 12
설계 > 데이터 프로젝션 > UI Composition
|5.MSAGoalsandDesignPatterns
• API Composition
• Have your user interfaces directly make API
calls and map them to UI controls (e.g., web-
based UI using JavaScript to get JSON via HTTP).
• API Gateway
• Have a server-side aggregation endpoint, or API
gateway, which can marshal multiple backend
calls, vary and aggregate content if needed.
• Backends for Frontends
• Restrict the use of the backends to one specific
user interface or application. This makes each
service more self-contained and independent
with its own UI and own backend.
Sam Newman, Building Microservices: Designing Fine-Grained Systems, 2015.
13. 13
설계 > 데이터 프로젝션 > Composite Service
|5.MSAGoalsandDesignPatterns
• 데이터 통합을 수행하는 별도의 추가적 마이크
로 서비스를 개발함
• 하나이상의 마이크로서비스를 호출한 결과를
하나의 데이터 (JSON) 로 융합하여 리턴하는
코드를 작성
• 데이터 전환 등의 작업을 동반할 수 있음
• 여러서비스 호출의 결과를 기다려야 하기 때문
에 블로킹이 발생 메모리 사용이 높아질 수
있음
• 호출된 하나의 서비스가 성능이 느린 경우 장
애 전파가 발생 가능
• GraphQL 서버를 컴포지트 서비스로 대체하면 프로
그래밍 없이 얻고자 하는 데이터 결과를 GraphQL 방
식의 파라미터로 받아서 하나 이상의 마이크로 서비
스 결과를 융합 조회할 수 있음
Modified from Microservices Patterns, Chris Richardson, Manning, 2018
≪aggregate≫
Charge
Accounting Service
≪aggregate≫
Delivery
Delivery Service
≪aggregate≫
RestaurantOrder
Kitchen Service
≪aggregate≫
Order
Order Service
Find Order
Composer
GET/orders/
{orderId}
GET/tickets?
orderId=
{orderId}
GET/deliveries?
orderId=
{orderId}
GET/charges?
orderId=
{orderId}
GET/order/{orderId}
Order status view
Order id : 3492-2323
Restaurant : Ajanta
Status : En route
ETA : 6:25 PM
Payment : Paid
Order status
frontend
14. 14
설계 > 데이터 프로젝션 > ES, CQRS, Multiple Read Models
|5.MSAGoalsandDesignPatterns
• 로컬 데이터베이스에 조회하고 싶은 데이터 모
델을 준비함
• 하나 이상의 데이터 소스가 변경될 때 마다의
이벤트를 수신하여 자체 데이터베이스에 반영
함
• 참조하고자 하는 데이터 원본 테이블의 구조와
관계없이 자체 마이크로서비스가 원하는 형태
로 데이터를 적재함
• 자체 데이터베이스를 참조하기 때문에 데이터
참조에 블로킹이 발생하지 않음
• 자체 데이터베이스 레이아웃을 사용하기 때문
에 Polyglot Persistence 를 통한 자치성이 높음
Order Service
Kitchen
Service
Delivery
Service
Accounting
Service
Order Service
Order history
view database
Order
Events
Ticket
Events
Delivery
Events
Accounting
Events
findOrderHistory( )
findOrder( )
Event
handlers
(Materialized View)
Modified from Microservices Patterns, Chris Richardson, Manning, 2018
15. 설계 > 접근별 비교 분석
|5.MSAGoalsandDesignPatterns
비교항목 Composition by UI Composition by API Composition by ES,
CQRS, Materialized
View
블로킹 발생 No Yes No
UI 구현 복잡성 High Low Low
Latency Mid High Low
Configuration 복잡도 Mid Low High
리소스 사용 Low/High High Low