서버 애플리케이션 서비스 설계하기(with MSA, DDD)

 
정확하지 않은 정보가 존재할 수 있음을 알려드립니다.
 

이벤트 스토밍 기법을 사용한 서버 애플리케이션 설계

이벤트 스토밍 기법이란?

시스템에서 발생하는 이벤트 중심으로 도메인을 식별하고 개발을 위한 설계를 진행합니다.
 

이벤트 스토밍 용어

먼저 이벤트 스토밍 기법에서 사용되는 용어에 대해서 알아보겠습니다.
 
1.  커맨드 : 사용자 액션을 지칭합니다. (예 : 사용자 생성링크 선택)
2. 이벤트 : 커맨드로부터 발생된 것이나 특정 행위를 지칭합니다. ~됨 수동태로 표현됩니다.(예 : 사용자 생성정보 입력됨, 사용자 생성됨)
3. 외부서비스 : 애플리케이션 기준으로 외부 서비스를 지칭합니다. (예: SMTP 서비스)
4. 애그리거트 : 컨텍스트를 나누는 개념을 지칭합니다 (예: 사용자, 주문)
    보충 : 1,2,3번 등을 그루핑 할 수 있는 개념을 지칭합니다.
 

UI 설계

이벤트 스토밍을 할 때 참고하기 위한 UI를 구성해 봅니다.
저는 유튜브 채널로 모의투자를 진행하는 웹페이지를 구상해 보았습니다.
코인거래 사이트를 조합하여 간단히 구성했음을 알려드립니다.
 

1. 메인화면

2. 차트화면 및 거래화면

3. 포트폴리오 화면

이벤트 스토밍 과정

1. 제작하고자 하는 시스템의 시나리오 별로 이벤트, 커맨드, 외부서비스를 식별합니다.

해당과정의 이후에 발생할 커뮤니케이션 비용을 줄이는 것을 목표로 합니다.
시스템에 대한 모든 이해관계자들이 참여하여 사용될 용어(유비쿼터스 언어)를 정의하고 비즈니스에 대해 동일한 이해를 갖기 위해 노력합니다.
 

회원가입 유스케이스

 
좌측부터 우측으로 시간의 흐름을 나타내고 색깔로 시나리오에 대한 요소를 식별할 수 있도록 구성합니다.
 
각 색깔이 의미하는 것은 아래와 같습니다.
파란색 : 사용자의 액션을 지칭하는 커맨드를 표현합니다.
노란색 : 발생되는 이벤트를 표현하며 수동태로 표현하는 것을 권장합니다.
빨간색 : 외부 시스템을 지칭합니다.
 

2. 식별된 컨텍스트를 그루핑 하여 애그리거트 식별

애그리거트 식별

 
시나리오 별로 생성된 컨텍스트(포스트잇)을 개념적으로 그루핑 합니다.
현재 예제에서는 하나의 시나리오만 예를 들어 표현하면 "사용자"와 "웹훅"으로 그루핑 할 수 있습니다.
그루핑 된 개념을 애그리거트라고 지칭합니다.
 
이렇게 애그리거트는 컨텍스트를 나누는 개념이 됩니다.
 

3. 애그리거트로 도메인과 서비스 후보 식별하기

2번 과정에서 정의한 애그리거트는 도메인의 후보가 됩니다.
 
이제 애그리거트를 기반으로 도메인을 식별하겠습니다. 대부분의 경우에는 애그리거트와 도메인이 1:1일로 대응지만, 이때 모호한 관계가 식별될 수 있습니다.
예를 들어 "유튜브 채널"과 "채널주식"이 정의되었을 때 두 애그리거트의 의존성이 높고 1:1의 관계를 맺는다면, 즉 다시 말해 2개의 애그리거트가 비즈니스 적으로 강하게 결합되어 있다면 하나의 도메인으로 정의하는 것이 좋습니다.

위 과정을 통해 유튜브채널 도메인과 그 안에 채널 서비스, 주식 서비스 후보가 식별됩니다.
 

4. 바운디드 컨텍스트 정의하기

MSA의 경우 도메인과 도메인사이의 결합을 끊어내여 작은 애플리케이션으로 개발해야 되기 때문에 3번에서 정의된 도메인을 기준으로 다른 도메인과의 경계를 정의합니다.
 
이때 이 경계를 바운디드 컨텍스트라고 지칭합니다.
 

예시. 도메인마다 같은 애그리거트가 다른 용어로 명확히 분리되는 행복한 경우

 
개발을 진행하면서 바운디드 컨텍스트에 걸쳐있는 개념은 마이크로 서비스마다 모두 구현이 필요합니다.
예를 들어 대여 서비스에서 사용자는 대여라는 개념이 더해진 대여자로, 구매 서비스에서는 구매자로 구현됩니다.
이처럼 경계의 걸쳐있는 개념은 서비스에 특화된 개념이 더해져야 완벽한 의미를 갖게 됩니다.
 
단, 위와 유사한 상황에서 같은 구현을 가지게 되더라도 각각 구현된 개념은 각 도메인에 대해 특화되고 의존적이며 서로 다른 개념임을 인지하여야 합니다.
 

5. 반복적 설계

많은 사람들이 한 번에 완벽한 설계를 할 수 없다고 말합니다.
개발을 진행하며 앞선 과정을 통해 수정해 나가며 도메인 설계를 구체화합니다.
 

6. 보리스(Boris) 다이어그램

서비스 후보 간 상관관계를 정의하는 다이어그램입니다.
서비스 후보끼리 동기/비동기로 소통하는지, 누가 누구에게 어떤 정보를 요청하는지 정의합니다.

BFF(Backend For Frontend)란 BFF란 Backend For Frontend의 줄임말로, 프런트엔드에 표현될 데이터를 위한 백엔드입니다. 단순하게 말해  api를 사용하는 클라이언트를 지칭합니다.
 

7.  snaps 작업

실제 개발하기 위해 정보들을 정리하는 작업을 진행합니다.
boris다이어 그램을 기반으로

• API,
• DATA,
• User-story,
• Risk
• data 등을 정의합니다.

 
user-story는 "사용자가 뭐가 필요해서 무엇을 한다" 관점에서 구성됩니다.
유저스토리는 이후에 백로그가 되기 때문에 구체적으로 작성하길 권장합니다.
ex. (~ 사용자가 보유주식을 매도하기 위해) 매도 요청 (을한다.), 매수 요청
 
해당 작업이 끝나면 백로그와 api, dto 등을 명세할 수 있고 이를 기반으로 실제 개발에 들어갈 수 있습니다.
TDD/ATDD  방식으로 개발을 진행한다면, 유저스토리 각각이 하나의 테스트가 되어 개발을 진행할 수 있습니다.

결론

이벤트 스토밍은 도메인 기반으로 점진적으로 설계하기 좋은 방법인 것 같습니다.
굳이 MSA나 DDD 관점이 아니더라도 프로젝트를 시작하기 전에 도입하여 설계를 이끌어내기에 좋은 방법이라고 생각합니다.
 

부록(이벤트 스토밍 전체 결과)

1. 이벤트 식별 결과

이벤트 식별 결과

 

2. 애그리거트, 도메인후보, 서비스후보, 바운디드 컨텍스트 식별과정 결과

애그리거트,도메인, 서비스 후보 및 바운디드 컨텍스트 식별

 

3. 주요 기능 보리스 다이어그램 식별

좌측 : 포트폴리오 보리스 다이어그램 / 우측 : 매도&매수 보리스 다이어그램