Dev. 내가 본 서적

책 리뷰 - 반버논, "도메인 주도 설계 핵심", 박현철 전장호 옮김, 에이콘출판, 2017.

삘쏘굿 2020. 12. 4. 14:54

정보

출간일 : 2017년 09월 25일

쪽수/무게/크기 : 208쪽 | 402g | 188*235*20mm

ISBN13 : 9791161750576




선정이유

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

저자의도

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

목차

1장. 나에게 도메인 주도 설계는


__DDD가 우리에게 상처를 줄까?
__좋은 나쁜 그리고 효과적인 설계
__전략적 설계
__전술적 설계
__학습 과정과 지식의 정제
__이제 시작해보자!




2장. 바운디드 컨텍스트 및 보편언어와 전략적 설계


__도메인 전문가와 비즈니스 동인
__사례 연구
__기본적인 전략적 설계를 하려면
__도전과 통합
__보편언어 개발하기
____작업에 시나리오 넣기
____많은 시간과 노력이 드는 일은?
__아키텍처
__요약




3장. 서브도메인과 전략적 디자인


__서브도메인은 무엇인가?
__서브도메인의 유형
__복잡성 다루기
__요약




4장. 컨텍스트 매핑과 전략적 설계


__매핑의 종류
____파트너십
____공유 커널
____고객-공급자
____준수자
____반부패 계층
____공개 호스트 서비스
____공표된 언어
____각자의 길
____큰 진흙 덩어리
__컨텍스트 매핑 활용하기
____SOAP을 이용한 RPC
____레스트풀 HTTP
____메시징
__컨텍스트 매핑 사례
__요약




5장. 애그리게잇과 전술적 설계


__왜 필요할까
__애그리게잇 경험 법칙
____규칙 1: 애그리게잇 경계 내의 비즈니스 불변사항을 보호하라
____규칙 2: 작은 애그리게잇을 설계하라
____규칙 3: 오직 식별자로만 다른 애그리게잇을 참고하라
____규칙 4: 결과적 일관성을 사용해 다른 애그리게잇을 갱신하라
__애그리게잇 모델링
____추상화를 조심스럽게 선택하라
____올바른 크기의 애그리게잇
____테스트 가능한 단위
__요약




6장. 도메인 이벤트와 전술적 설계


__도메인 이벤트를 설계, 구현, 사용하기
__이벤트 소싱
__요약




7장. 가속화와 관리 도구


__이벤트 스토밍
____다른 도구들
__애자일 프로젝트에서의 DDD 관리
중요한 일부터 먼저
____SWOT 분석 사용
____모델링 스파이크와 모델링 부채
____작업 확인 및 노력 추정
__기간이 정해진 모델링
____어떻게 구현해야 하는가?
____도메인 전문가와 상호 작용하기
__요약

독서전략

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

요약정리

온라인 DDD 트레이닝 제공 : http://ForComprehension.com
  • 그런데 지금은 무료로 제공해주는 세션은 없는듯



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

설계 방법 요약
  1. 전략적 설계 - 큰 붓 터치
    1. 바운디드 컨텍스트
  • 바운디드 컨텍스트라는 전략적 설계 패턴을 사용해서 도메인 모델을 분리
  • 보편언어
    • 개발자와 도메인 전문가의 협업을 통해 분리한 도메인 모델을 보편언어로 개발
    • 이 단계에서 이벤트 스토밍 세션을 진행하는 것은 도움이 된다.
  • 서브도메인
    • 하나의 논리적 도메인 모델. 보통 하나의 바운디드 컨텍스트는 하나의 서브도메인을 가진다.
    • 종류
      • 핵심도메인
      • 지원 서브도메인
        • 기존 제품으로 해결할 수 없는 맞춤 개발이 필요한 모델링 영역
      • 일반 서브도메인
        • 기존 제품 구매를 통해 충족시킬 수 있는 경우
  • 컨텍스트 매핑
    • 컨텍스트 매핑으로 여러 개의 바운디드 컨텍스트 통합
    • 컨텍스트 맵 - 2개의 바운디드 컨텍스트를 통합하며 그 사이에 존재하는 팀의 관계, 기술적 매커니즘을 정의


  • 전술적 설계 - 세밀한 얇은 붓 터치
    1. 애그리게잇
    • 엔터티와 값 객체를 알맞은 크기의 애그리게잇으로 묶음
      • 설계 가이드
        • 애그리게잇 경계 내에서 비즈니스 불변사항들을 보호하라.  - 트랜잭션
        • 작은 애그리게잇을 설계하라.
        • 오직 ID를 통해 다른 애그리게잇을 참고하라.
        • 결과적 일관성을 사용해 다른 애그리게잇을 갱신하라. - 멱등성
    1. 도메인 이벤트
      • 전술적 설계 노력을 통해 도메인 이벤트가 도메인 모델에 구체화되고, 도메인 이벤트가 만들어지면 바운디드 컨텍스트와 다른 자원들은 이벤트를 받아 활용한다. 이는 중요한 이벤트에 관심이 있는 이벤트 리스너들에게 관련 상황의 발생을 알리는 강력한 방법이다. 


      이벤트 스토밍 ( 출처 : 도메인 주도 설계 핵심, 에이콘, 반 버논 지음. 박현철, 전장호 옮김 )
      • 빠른 주기의 학습 과정에 도메인 전문가와 개발자 모두가 참여하는 신속한 설계 기술. 명사나 데이터 보다 비즈니스와 비즈니스 프로세스에 초점을 맞춤.

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




        • 준비

        • 용어
          • 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.
        • 기본컨셉

        • 진행 예시




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




      총평

      확실히 빠르게 개념을 훑기에 분량이나 내용이 적당한 듯 싶다.
      그런데 DDD에 대한 개념이 전혀 없는 상태에서 읽었을 때에도 지금처럼 술술 읽혔을까 하는 의구심이 약간 들기는 하지만...
      어쨋든 이 책을 통해 설계의 전체 흐름을 이해하고 이벤트 스토밍 방법을 정리 할 수 있었던 것이 가장 큰 성과였 던 것 같다.