Kubernetes Day05
Day05
MSA 이벤트 스토밍
DDD (Domain Driven Design)
Domain-driven design(DDD)은 Domain별로 나누어 설계하는 방식이다. 기존의 어플리케이션 설계가 비즈니스 Domain에 대한 이해가 부족한 상태에서 설계 및 개발되었다는 반성에서 출발하였다. DDD의 핵심 목표는 ‘Loosly coupling’, ‘High cohesion’이다. 즉, 어플리케이션 또는 그 안의 모듈간의 의존성은 최소화하고, 응집성은 최대화하는 것이 목표이다. DDD는 Strategic Design과 Tactical Design으로 나눌 수 있다. Strategic Design은 개념 설계이고 Tactical Design은 프로그래밍하기 위한 구체적 설계라고 할 수 있다. 이 접근법은 필요한 사람들의 복잡한 요구사항에 초점을 맞추고 불필요한 것에 노력을 낭비하지 않는 소프트웨어 개발을 가능하게 한다.
마이크로서비스 이벤트 스토밍
Alberto Brandolini라는 이탈리아 출신 DDD 컨설턴트가 DDD 설계를 가속화시킬 수 있는 설계 기법을 고안해 냈는데 이 방법은 이벤트 중심으로 이해 관계자들이 모여 브레인 스토밍하는 워크샵이라 하여 이벤트 스토밍이라고 부른다. 이벤트 스토밍이란, 소프트웨어를 개발하고자 하는 도메인에서 어떤 일들이 이뤄지고 있는지 빠르게 파악할 수 있는 워크샵 형태의 방법이다. 개발자 뿐만 아니라 도메인 전문가, 기획자, 디자이너, 테스터 등 해당 소프트웨어 개발의 모든 이해관계자들이 참여한다. 참여자들은 이벤트, 커맨드, 리드 모델, aggregate, 외부 시스템 등을 나타내는 서로 다른 색깔의 포스트잇들을 벽에 붙여가며 이벤트 스토밍을 진행하게 된다. MSA를 설계할 때는 비즈니스적으로 재사용될 여지가 많게끔 쪼개는 것이 좋다.
사전준비
- 공간 : 깨끗한 벽을 가진 넓은 워크샵 공간
- 참가자 : 고객, 도메인 전문가, 설계자, 개발자, 테스트 등 모든 이해 관계자
- 준비물 : 벽에 붙힐 A1 하얀색 전지, 마커 펜, 다양한 색의 포스트 잇, 줄을 그릴 수 있는 다양한 색깔의 끈 테이프, 스카치 테이프
- 마음가짐 : 적극적이고, 긍정적이며 열린 마음가짐, 대화하고 토론하고 나설 수 있는 용기
- facilitator : 열린 분위기로 활동을 촉진하고 리딩하는 사람
협업 플랫폼 소개
진행 방식 예제
간략한 진행 과정
- 이벤트스토밍에 필요한 화이트 보드 벽면과 수행에 필요한 스티커를 준비한다.
- 도메인 전문가와 기획자, 개발 전문가와 함께 사용자 시나리오, 또는 업무 요건을 리뷰한다.
- 가장 먼저 발생 가능한 Event를 무작위로 도출하고 Policy, Command, Aggregate 순서로 이벤트를 중심으로 스티커별 해당 내용을 정의하고 발생시간 순서로 벽면에 부착한다.
- Bounded Context를 설정하고 서브 도메인 간의 컨텍스트 맵핑을 통해 BC간의 정보 참조의 릴레이션을 정의한다.
스티커 유형
- Domain Event(Orange)
- P.P 형태의 동사
- 이벤트 퍼블리싱
- Command(Sky Blue)
- 현재형으로 작성
- 행동, 결정 등의 값들에 대한 정의
- UI 혹은 API
- Read Model(Green)
- 행위와 결정을 하기 위하여 유저가 참고하는 데이터
- 데이터 프로젝션이 필요 : CQRS 등으로 수집
- Policy(Lilac)
- 업무 정책, 이벤트에 대한 반응
- Actor(Yellow)
- 사용자, 페르소나, 스테이크 홀더, 유저 인터페이스를 통해 데이터를 소비하고 명령을 실행하여 시스템과 상호작용
- Aggregate(Yellow)
- 비즈니스 로직 처리의 도메인
- 객체 덩어리
- 서로 연결된 하나 이상의 데이터 및 value objects의 집합체
- External System(Pink)
- 외부 시스템
- 시스템 호출을 암시(REST)
- Comment or Question(Purple)
- 추가적인 내용 입력
- 예측되는 Risk
- Definition
- 도메인에 대한 용어 등의 설명, 기술
실제 진행 과정
[Step 1] Event 정의
- 가장 먼저 서비스에서 발생하는 비즈니스 이벤트를 도출한다.
- 가급적 현업이 사용하는 용어를 그대로 사용(Ubiquitous Language)하여 오렌지색 스티커에 이벤트를 기술하고 이를 벽면에 붙인다.
- 비즈니스 이벤트에 과거형으로 작성하는데 도메인 내부에 상태가 변화되고 난 결과가 이벤트이다.
[Step 2] Policy 정의
- 이벤트 스토밍의 두 번째 수행 대상은 Policy 도출
- Policy는 이벤트가 발생한 후 연이어 발생하는 반응형 액션으로, 한 서비스 이벤트에 대해 수행되어야 할 타 서비스의 액션들로, 먼저 정의된 이벤트 아래에 덧대어 붙인다.
- 하나의 이벤트에 반응하여 수행되어야 할 policy는 여러 팀에서 도출된 멀티 액션이 존재할 수 있다.
[Step 3] Command 도출
- 세 번째로 Event를 발생시키는 행위인 커맨드를 도출하는데, 도메인 내의 어떠한 상태 변화를 일으키는 서비스를 말한다.
- 웹 페이지 내에서 버튼을 클릭하는 User Decision이 여기에 해당한다.
- 도출된 커맨드는 이벤트 스티커 앞쪽에 붙여, 스티커를 통한 나레이션이 되도록 정렬한다.
[Step 4] Actor 정의
- Actor는 커맨드를 발생시키는 주체(사람, 시스템 등)을 말한다.
- Actor는 담당자 또는 시스템이 될 수 있으며, 직관적으로 파악될 수 있는 액터의 경우, 표시하지 않아도 무방하다.
- 도출된 액터는 유저 스토리에 가까운 나레이션이 가능하도록 해당 커맨드 스티커 왼쪽에 배치한다.
[Step 5] Aggregate 정의
- Aggregate는 ‘결합물’을 의미하는데 어떠한 도메인 객체를 중심으로 하나의 ACID한 트랜잭션에 묶여 변화되어야 할 객체의 묶음을 도출하고, 그것들을 커맨드, 이벤트와 함께 묶는다.
[Step 6] Bounded Context 도출
- Bounded Context는 동일한 문맥으로 효율적으로 업무 용어(도메인 클래스)를 사용할 수 있는 객체 범위를 뜻한다.
- 하나의 BC는 하나 이상의 aggregate를 원소로 구성될 수 있다.
- 이 BC를 마이크로서비스 구성 단위로 정하게 되면 이를 담당하는 팀내의 커뮤니케이션이 효율화 된다.
[Step 7] Context 맵핑
- Bounced Context까지 도출된 이후에 BC간 정보 참조 릴레이션 설정(혹은, 이벤트가 발생한 이후 동반된 행위의 호출 관계를 선으로 표시)하는 작업을 ‘Context 맵핑’이라고 한다.
- 컨텍스트 간 맵핑 정보만 보더라도 전체 도메인 서비스의 참조 토폴로지(topology)를 한 눈에 파악이 가능하다.
이벤트 스토밍의 효과
- 커뮤니케이션 비용 절감
이벤트 스토밍을 모든 직군이 참여해 진행하면서 비즈니스 플로우를 한 눈에 볼 수 있게 되었고, 보편 언어를 구축해 서로 동일한 언어로 소통하게 됨으로서 커뮤니케이션 비용이 매우 줄어들었다.
- 기획에서의 빈틈 발견
이벤트 스토밍은 기획과 대략적인 디자인이 진행된 이후에 진행된다. 이렇게 되면 기획 내용을 기반으로 이벤트 스토밍을 진행하면서 기획의 빈틈을 발견하고 메꿀 수 있다. 도메인에서 발생할 수 있는 모든 이벤트들을 시간 순서대로 나열하다보면, 특정 이벤트들에 대한 기획이 빠져 있는 것을 발견하기 쉽다.
개발자의 꿀팁
면접
- 기본적인 태도는 갖추어야 한다.
- 면접 때 면접관이 많이 물어볼 수 있도록 다양한 프로젝트를 이력서에 써서 제출하면 좋다.
- 해당 프로젝트를 진행하면서 어려웠던 점들과 해당 부분을 해결한 방법 같은 것을 숙지하고 가면 좋다.
미팅
- 다른 사람의 의견에 반대되는 의견을 낼 때는 다른 사람의 의견을 존중해주면서 조심스럽게 나의 의견을 피력하는 것이 중요하다.
- 공격적인 비판을 하면 서로 자신의 의견을 관철시키기 위해 방어하기 때문에 절대 팀워크가 이루어지지 않는다.
직장
- 좋은 회사에 가면 이직할 때 또다른 좋은 회사로 이직할 수 있도록 주변에서 이끌어준다. 따라서 처음부터 좋은 회사로 가는 것이 좋다.