소림사의 홍반장!

선정이유

• 개념을 가볍고 빠르게 훑어 볼 수 있다는 주변 개발자들의 추천.

저자의도

• 이 책은 누구를 위한 것인가? 에 대해 확실히 얘기 하고 있다.
• DDD핵심과 도구를 배우는 것에 관심을 갖고 이를 빠르게 학습하고자 하는 사람들을 위한 것.
• DDD 사용을 권장했던 고객과 함께 일하고 있는 컨설턴트 - 주요 이해관계자를 신속하게 이해시킬 수단으로 이 책을 사용
• DDD와 친숙하지 않은 개발자와 함께 작업하면서 DDD를 조만간 사용해야 한다면 이 책을 읽도록 권유
• 도메인 주도 설계 구현 [IDDD] - 책 전반에 걸쳐 심화 개념은 이 책을 살펴보라고 얘기하고 있다.
• 큰 틀에서 개념을 익히고 난 후 심화 학습을 권장하고 있다.

목차

독서전략

• 208쪽. 지교적 작고 얇은 책이라 2주간 출퇴근시간에 10분씩만 읽어도 충분히 완독가능할 듯.
• 읽고나서 필수용어와 요점을 다시 정리해 보도록 한다.
• 설계의 순서가 목차의 순서임을 인지하고 읽도록 한다.

요약정리

• 그런데 지금은 무료로 제공해주는 세션은 없는듯

• Bounded Context
• 의미적으로 동일한 컨텍스트의 범위를 표현.
• 주로 바운디드 컨텍스트마다 각각 분리된 소프트웨어 산출물이 나온다.
• Ubiquitous Language
• 팀 구성원들이 이야기할 때 사용되는 언어.
• 엄격하고, 정확하고, 엄중하며, 단호해야 함.
• 소프트웨어 모델 안에 구현.
• Subdomain
• 하나의 논리적 도메인 모델
• context mapping
• 컨텍스트 매핑으로 여러 개의 바운디드 컨텍스트 통합
• Aggregate
• 엔터티와 값 객체를 알맞은 크기의 애그리게잇으로 묶음
• 도메인 이벤트
• 의존관계 일관성을 제공하도록  바운디드 컨텍스트 내의 비즈니스 과점에서 중요한 사항들에 대한 기록.
• 이벤트 소싱
• 애그리게잇 인스턴스에 대해 변경된 것데 대한 기록으로 발생했던 모든 도메인 이베트를 저장하는 것을 말함. 발생했던 각 도메인 이벤트 모두를 저장.
• CQRS(Command Query Responsebility Segregation)
• 상태를 변경하는 기능과 상태 정보를 조회하는 기능을 분리하여 도메인을 구성하는 것
• CQRS 장점
• 명령과 조회 로직이 분리되어 각각의 복잡도 낮아짐
• 조회 성능 향상
• CQRS 단점
• 구현해야 할 코드량이 많아짐
  
• 더 많은 구현 기술이 필요
• 유지 비용 증가
• 분리된 저장소의 데이터 동기화 이슈
• 사용하지 않아야 할 경우
• 도메인 또는 비즈니스 규칙이 간단한 경우.
  
• 대규모의 고차원적인 어플리케이션이 아닌 경우.

1. 전략적 설계 - 큰 붓 터치
1. 바운디드 컨텍스트

• 바운디드 컨텍스트라는 전략적 설계 패턴을 사용해서 도메인 모델을 분리

• 개발자와 도메인 전문가의 협업을 통해 분리한 도메인 모델을 보편언어로 개발
• 이 단계에서 이벤트 스토밍 세션을 진행하는 것은 도움이 된다.

• 하나의 논리적 도메인 모델. 보통 하나의 바운디드 컨텍스트는 하나의 서브도메인을 가진다.
• 종류
• 핵심도메인
• 지원 서브도메인
• 기존 제품으로 해결할 수 없는 맞춤 개발이 필요한 모델링 영역
• 일반 서브도메인
• 기존 제품 구매를 통해 충족시킬 수 있는 경우

• 컨텍스트 매핑으로 여러 개의 바운디드 컨텍스트 통합
• 컨텍스트 맵 - 2개의 바운디드 컨텍스트를 통합하며 그 사이에 존재하는 팀의 관계, 기술적 매커니즘을 정의

  

  

  
  

1. 애그리게잇

• 엔터티와 값 객체를 알맞은 크기의 애그리게잇으로 묶음

• 설계 가이드
• 애그리게잇 경계 내에서 비즈니스 불변사항들을 보호하라.  - 트랜잭션
• 작은 애그리게잇을 설계하라.
• 오직 ID를 통해 다른 애그리게잇을 참고하라.
• 결과적 일관성을 사용해 다른 애그리게잇을 갱신하라. - 멱등성

• 전술적 설계 노력을 통해 도메인 이벤트가 도메인 모델에 구체화되고, 도메인 이벤트가 만들어지면 바운디드 컨텍스트와 다른 자원들은 이벤트를 받아 활용한다. 이는 중요한 이벤트에 관심이 있는 이벤트 리스너들에게 관련 상황의 발생을 알리는 강력한 방법이다. 

• 빠른 주기의 학습 과정에 도메인 전문가와 개발자 모두가 참여하는 신속한 설계 기술. 명사나 데이터 보다 비즈니스와 비즈니스 프로세스에 초점을 맞춤.
  
  
• 이벤트 스토밍의 이점
• 매우 구체적인 접근법이다. 모두가 학습 및 설계 세션에 기여해야 할 책임을 갖는다. 비즈니스 측 사람들과 개발자 모두가 함께 같은 곳에 서서 함께 학습한다. 모두가 보편언어를 함께 만든다.
• 모두가 이벤트와 비즈니스 프로세스에 집중한다.
• 매우 시각적인 접근법이다.
• 가장 빠르고 가장 적은 비용으로 수행할 수 있다.
• 팀의 이해의 폭을 획기적으로 증진시킬 수 있다. 주기적으로 항상
• 모든 사람들이 무언가를 배운다. 모든 사람이 잘못된 이해를 하지 않도록 만들면서 통일된 방향과 목표를 갖고 아픙로 나갈 수 있게 해준다.
• 모델과 모델을 이해하는 데 문제가 있다면, 이를 가능한 한 앞단계에서 빠르게 인지할 수 있다.
• 설계 수준 스토밍은 명확한 소프트웨어 산출물로 이어진다.
• 준비물
• 도메인 전문가, 개발자와 같이 프로젝트 개발에 관련이 있는 모든 사람들
• 여러가지 색깔의 접착력 좋은 정사각형의 포스트잇
• 주황색 : 도메인 이벤트
• 자주색 : 비즈니스 프로세스의 문제점
• 연보라섹 : 실행 프로세스
• 밝은 파란색 : 각 도메인 이벤트를 생성시키는 명령 
• 밝은 노란색 : 액션 수행자 또는 수행 역할
• 옅은 노란색 : 애그리게잇
• 분홍색 : 바운디드 컨텍스트 이름
• 초록색 : 중요한 뷰
• 굵고 명확하게 쓸 수 있는 검정 펜
• 넓은 벽
• 긴 종이 두루마리
• 스토밍 세션 진행방법
• 도메인 이벤트를 포스트잇에 적으면서 비즈니스 프로세스를 도출
• 비즈니스 프로세스에 최우선적으로 초점을 둠
• 도메인 이벤트의 이름은 과거형 동사
• 시간 순서대로 붙일 것. 왼쪽에서 오른쪽으로 도메인에서 발생하는 이벤트 순서.
• 병형 프로세싱 구조는 다른 도메인 이벤트 하부에 위치시켜 수직적 공간을 활용한다.
• 진행 중 발견되는 기존 신규 비즈니스 프로세스의 문제점은 자주색 포스트잇에 왜 그것이 문제인지를 설명하는 문장을 적어 명확하게 표시.
• 도메인 이벤트의 결과에서 실행 프로세스를 도출해야 하는 경우 연보라 포스트잇에 이름을 적어두고, 도메인 이벤트에서 이름이 적힌 프로세스로 화살표를 연결해 그린다.
• 각 도메인 이벤트를 생성하는 명령을 정의
• 밝은 파란색 포스트잇에 그에 상응하는 각 도메인 이벤트를 생성시키는 명령의 이름을 적는다.
• 명령 포스트잇을 그 명령이 만드는 도메인 이벤트바로 옆에 붙여서 '명령/이벤트'처럼 서로 짝을 지어 관계를 형성.
• 정해진/ 제한된 시간에 도달하면 발생하는 도메인 이벤트의 경우에는 그에 상응하는 명령이 없을 수도 있다.
• 액션을 수행하는 특정한 사용자 역할이 있고, 이를 명시하는 것이 중요하다면, 작고 밝은 노란색의 포스트잇에 사람이나 그 역할의 이름을 적어 밝은 파란색의 명령 포스트잇의 하단 왼쪽에 붙여 놓자.
• 명령이 수행될 프로세스를 생성하기도 하므로 연보라색 포스트잇에 그 이름을 적고 명령에서부터 이름이 적힌 프로세스로 화살표를 그린다.
• 여러 개의 도메인 이벤트를 유발하는 명령을 오직 1개만 식별하였다면 1개의 명령 오른쪽에 여러 도메인 이벤트들을 위치시킨다.
• 도메인 이벤트 결과를 생성해내는 명령을 엔터티/애그리게잇에 연관시킨다.
• 애그리게잇 모델링 가이드라인
• 용어의 명칭이 중요한 것이 아니라 각각의 개념들을 모두 같은 개념으로 이해할 수 있는지가 중요하다.
• 포스트잇을 통해 애그리게잇이 나타내는 개념에 대해 팀이 명확하게 의사소통을 할 수 있어야 한다.
• 모든 애그리게잇에 옅은 노란색 포스트잇을 사용하고, 각각 애그리게잇 이름을 적는다.
• 명사형
• 모델 안에 있는 모든 애그리게잇에 대해 동일하게 수행
• 애그리게잇 포스트잇을 명령/도메인 이벤트 짝의 뒷쪽, 약간 윗쪽에 위치시킴
• 시간흐름에 따라 살펴보면 반복적으로 사용되는 애그리게잇을 발견할 수 있다. 재배치보다는 같은 애그리게잇 병사를 여러개의 포스트잇에 적고, 그에 상응하는 명령/이벤트 짝이 발생하는 곳마다 붙인다. 중요한 것은 비즈니스 프로세스를 모델링하는 것이며, 비즈니스 프로세스는 시간 흐름에 따라 수행된다.
• 새로 발견하는 도메인 이벤트는 무시하지 말고 모델링 공간 내에 상응하는 명령과 애그리게잇에 맞게 위치시킨다. 애그리게잇이 너무 복잡해지면 관리된 프로세스(연보라색)로 나눠야 한다.
• 모델링 공간에 경계선과 흐름을 보여주기 위한 화살표를 그린다.
• 경계점 찾기
• 서로 다른 비즈니스 측 사람들이 같은 용어에 대해 서로 다른 정의를 갖거나 개념이 중요하긴하나 핵심 도메인의 일부가 아닌 부서들간의 경계
• 컨텍스트와 경계들을 나타낼 때 바운디드 컨텍스트는 실선, 서브도메인은 점선으로 표시
• 여러 경계 영역에 분홍색 포스트잇을 붙이고, 경계 내에 해당 바운디드 컨텐스트 이름을 적는다
• 바운디드 컨텍스트 사이에 도메인 이벤트 흐름의 방향을 보여주기 위해 화살표 선을 그린다.
• 사용자들이 액션을 수행하기 위해 필요한 다양한 뷰들을 식별하고, 다양한 사용자들을 위한 주요 역할들을 파악
• 매우 중요하거나 특별한 주의를 기울여서 생성시켜야 하는 뷰에 한해 초록색 포스트잇을 사용해 나타낸다
• 사용자와 시스템의 상호작용에 대해 중요한 의미가 있거나 시스템이 특정 사용자만을 위해 동작하는 경우를 표현할 때만 밝은 노락색 포스트잇을 사용하여 주요 사용자 역할을 표현한다.

• 참고 - Wikipedia :: Event storming
• 준비

  

• 용어
• Aggregate
• Cluster of domain objects that can be treated as a single unit.
• Business process
• Processes a command according to business rules and logic. Creates one or more domain events.
• Command
• A command executed by a user through a view on an aggregate that results in the creation of a domain event.
• Domain event
• An event that occurs in the business process. Written in past tense.
• External system
• A third-party service provider such as a payment gateway or shipping company.
• User
• A person who executes a command through a view.
• View
• A view that users interact with to carry out a task in the system.
• 기본컨셉

  

• 진행 예시

  

• 언제 도메인 전문가와의 시간이 필요하고 그들이 개발자들을 도와줘야 하는 작업은 무엇인가?
• 이벤트 스토밍 세션
• 바운디드 컨텍스트 정의와 모델 시나리오 생성
• 모델의 정확성을 확인하는 테스트 검토
• 보편언어, 애그리게잇 이름, 명령, 도메인 이벤트를 개선하기 위해

총평