도메인 주도 설계 첫걸음.md

서평

• 
• 이 책은 가상 면접 사례로 배우는 대규모 시스템 설계 기초 책과 같이 추천을 받아서 읽게 된 책입니다. 도메인 주도 설계의 원칙과 패턴은 주니어, 시니어, 지원팀, 수석 등 모든 레벨의 소프트웨어 엔지니어에 유요한 책으로 데이터를 다루시는 분들은 가볍게 읽는 것을 권장드립니다. DDD는 소프트웨어를 모델링하고 효과적으로 구현하는 데 필요한 도구와 기법을 제공할 뿐만 아니라, 소프트웨어를 모델링하고 효과적으로 구현하는 데 필요한 도구와 기법을 제공할 뿐만 아니라, 소프트웨어 엔지니어링에서 자주 간과되는 관점인 맥락에 대해 밝혀주며 소프트웨어 엔지니어링의 중요한 관점에 대해서 배웠습니다.
• 이 책은 전략적 설계, 전술적 설계, DDD 실무, DDD와 다른 방법론 및 패턴과의 관계로 크게 네 개의 패턴으로 나누어집니다. 대형 소프트웨어 설계 의사결정에 필요한 도구와 기법에 대해 배우며 시스템의 비즈니스 로직을 구현하는 다양한 방법에 대해 코드를 중심으로 배웁니다. 또한 실제 프로젝트에 DDD를 적용하는 전략과 기법을 논의하며 도메인 주도 설계에 대해 논의하고 다른 방법론과 패턴 맥락에서 DDD에 대해 배웁니다.
  • 1부에서는 소프트웨어의 전략과 설계 측면에서 무엇과 왜에 대해 논의하며 비즈니스 도메인을 분석하고, 하위 도메인과 그 전략적 가치를 식별하고, 비즈니스 도메인에 대한 지식을 다양한 모델을 구현하는 소프트웨어 구성요소인 바운디드 컨텐스트 설계로 전환하는 방법에 대해 배웠습니다.
  • 2부에서는 전술적 설계 측면에서 방법에 대해 논의합니다. 시간 차원의 모델링과, 여러 아키텍처 패턴에 대해서 다양한 방법을 살펴봐서 좋았습니다.
  • 3부에서는 이론이 아닌 실무를 다루고 실제 프로젝트에 도메인 주도 설계를 적용하는 것을 배웁니다.
  • 4부에서는 DDD와 관련 있는 다른 방법론과 패턴에 대해 논의합니다. 마이크로서비스 기반 아키텍처 스타일과, 이벤트 주도 아키텍처, 데이터 메시 아키텍처와 도메인 주도 설계 간의 상호작용에 대해서 심도있게 다루고 있어서 좋았습니다.

전략적 설계

• 도메인 주도 설계(DDD: Domain-Driven Design)는 크게 2가지로 나눌 수 있다. 전략적 설계(strategic design) 단계에서 개발자와 비즈니스 전문가는 초기부터 협력하여 비즈니스 문제, 즉 도메인을 이해하고 문제를 서로 연결된 풀기 쉬운 작은 크기로 쪼갠다. 전술적 설계(tactical design)로서, 앞서 발견한 전략적 설계를 소프트웨어 아키텍처와 구현으로 전환시키는 단계다. DDD는 도메인을 잘 구성해 복잡성을 회피할 수 있는 가이드와 패턴을 제공한다.
• DDD의 전략적인 측면은 무엇?과 왜?라는 질문에 대한 정답을 찾는 것. 우리가 어떤 소프트웨어를 만드는지, 그리고 왜 그 소프트웨어를 만드는지에 대한 해답을 찾는 것.
• 전술적 측면은 어떻게?라는 방법에 대한 것으로 소프트웨어 각각의 구성요소가 구현되는 방법을 찾는 것

비즈니스 도메인 분석하기

• 비즈니스 도메인은 기업의 주요 활동 영역으로 회사가 고객에게 제공하는 서비스를 말함
• 하위 도메인
  • 하위 도메인은 비즈니스 활동의 세분화된 영역
  • 핵심 하위 도메인은 회사가 경쟁업체와 다르게 수행하고 있는 것
  • 일반 하위 도메인
    • 모든 회사가 같은 방식으로 수행하는 비즈니스 활동
    • 일반 하위 도메인은 회사에 경쟁력을 제공하지 않음. 이미 실무에서 검증된 솔루션으로 널리 이용 가능하며, 모든 회사에서 사용하고 있어서 더 이상 혁신이나 최적화가 필요 없음
  • 지원 하위 도메인
    • 회사의 비즈니스를 지원하는 활동
    • 핵심 하위 도메인과 달리 지원 하위 도메인은 어떠한 경쟁 우위도 제공하지 않음
• 도메인 분석 예제
  • BusVNext
    • 대중교통 회사. 고객에게 택시를 잡는 것처럼 쉽게 버스를 타는 경험을 제공하는 것이 목표
    • 핵심 하위 도메인
      • 라우팅
      • 분석
      • 모바일 앱 사용자 경험
      • 차량 관리
    • 일반 하위 도메인
      • 교통 상황
      • 회계
      • 청구
      • 권한 부여
    • 지원 하위 도메인, 프로모션과 관리 모듈은 회사의 핵심 비즈니스를 지원함
    • 설계 의사결정
      • 몇 가지 전략적인 설계 의사결정
        • 라우팅 알고리즘, 데이터 분석, 차량 관리, 앱 사용성은 가장 정교한 기술 도구와 패턴을 사용해서 사내에서 개발해야 함
        • 판촉 관리 모듈의 구현은 외부에 위탁할 수 있음
        • 교통 상황 식별, 사용자 권한 관리, 재무 및 거래 기록 관리는 외부 서비스 제공 업체에 맡길 수 있음
• 도메인 전문가(domain expert) : 우리가 모델링하고 코드로 구현할 비즈니스의 모든 복잡성을 알고 있는 주제 전문가로 도메인 전문가는 소프트웨어의 비즈니스 도메인에 대한 권위자

도메인 지식 찾아내기

• 비즈니스 문제
  • 우리가 개발하는 소프트웨어 시스템은 비즈니스 문제를 해결하는 솔루션
  • 비즈니스 문제는 워크플로와 프로세스 최적화, 수작업 최소화, 자원 관리, 의사결정 지원, 데이터 관리 등과 관련된 과제일 수 있음
  • 비즈니스 문제는 비즈니스 도메인과 하위 도메인의 모든 수준에서 발생할 수 있음
• 도메인 지식 찾아내기
  • 효과적인 소프트웨어는 도메인 전문가가 문제를 생각하는 방식, 즉 멘탈 모델을 모방해야 함
• 커뮤니케이션
  • 거의 모든 소프트웨어 프로젝트에는 도메인 전문가, 프로젝트 소유자, 엔지니어, UI와 UX 디자이너, 프로젝트 매니저, 테스터, 분석가 등 다양한 역할의 이해관계자의 협업이 필요하다고 할 수 있음
  • 전형적인 소프트웨어 개발 생애주기에서 도메인 지식은 분석 모델(analysis model)로 알려진 엔지니어 친화적인 형태로 변환됨. 분석 모델은 도메인 지식 이면에 존재하는 비즈니스 도메인에 기반하기보다는 시스템 요구사항을 설명한 것에 지나지 않음
• 유비쿼터스 언어
  • 참가자들이 효과적으로 소통하기 위해 변환에 의존하지 말고 같은 언어를 사용하는 것
  • 전통적인 소프트웨어 개발 생애주기에서 변환이 어떻게 일어나는지 정리
    • 도메인 지식이 분석 모델로
    • 분석 모델이 요구사항으로
    • 요구사항은 시스템 설계로
    • 시스템 설계는 소스코드로
  • 도메인 주도 설계에서 이같이 도메인 지식을 계속해서 변환하는 대신, 비즈니스 도메인을 설명하기 위한 단일화된 언어 체계를 세우고자 하는데, 이것이 바로 유비쿼터스 언어
• 비즈니스 언어
  • 유비쿼터스 언어는 도메인 전문가의 이해와 비즈니스 도메인에 대한 멘탈 모델을 쉽게 이해할 수 있는 관점으로 표현하는 것을 목표로 함
  • 시나리오
    • 광고 캠페인 관리 시스템 만들시 가정
      • 광고 캠페인은 다양한 창의적인자료를 전시할 수 있다
      • 캠페인은 최소한 하나의 광고 할당이 활성화되어야 게시된다
      • 판매 커미션은 거래가 승인된 후에 회계 처리된다
    • 모든 문장은 비즈니스 언어로 작성됐음. 문장은 비즈니스 도메인을 바라보는 도메인 전문가의 시각을 반영함.
    • 철저하게 기술적이어서 유비쿼터스 언어의 개념에 맞지 않은 문장
      • 광고의 아이프레임(iframe)은 HTML 파일을 표시함
      • 캠페인은 활성-할당(active-placement) 테이블에 하나의 연관 레코드가 있어야 게시됨
      • 판매 커미션은 거래(transaction) 테이블과 판매-승인(approved-sales) 테이블의 연관 레코드에 근거하여 처리됨
    • 일관성
      • 가정할 필요가 없어야 하고 비즈니스 도메인의 로직을 명료하게 표현해야 함
    • 모호한 용어
    • 동의어 : 유비쿼터스 언어에서 두 용어는 서로 바꿔 사용할 수 없음
• 비즈니스 도메인 모델
  • 효과적인 모델링
    • 모든 모델에는 목적이 있고 효과적인 모델은 그 목적을 달성하는 데 필요한 세부사항만 포함함
    • 유용한 모델은 실세계의 복사본이 아니라 문제를 해결하려는 의도가 있으며, 그 목적에 필요한 정보만 제공해야 함
  • 도구
    • 위키는 유비쿼터스 언어를 수집하고 관리하는 용어집(glossary)으로 사용될 수 있음. 이런 용어집은 비즈니스 도메인의 용어에 대한 정보를 얻을 수 있는 거점 역할을 하므로 새로운 팀원이 쉽게 적응하게 해줌

도메인 복잡성 관리

• 바운디드 컨텍스트
  • 유비쿼터스 언어를 여러 개의 작은 언어로 나눈 다음 각 언어를 적용할 수 있는 명시적인 바운디드 컨텍스트(bounded context)에 할당
  • 모델의 경계(바운디드 컨텍스트)를 정의하는 것은 모델링 프로세스의 본질적인 부분
• 실생활의 바운디드 컨텍스트
  • 시맨틱 도메인(semantic domain)
    • 의미 영역과 해당 의미를 전달하기 위해 사용하는 단어 영역으로 구분함

바운디드 컨텍스트 연동

• 컨트랙트(contract) : 바운디드 컨텍스트 사이에는 항상 접점이 있는데 이것을 의미함
• 각 컨트랙트는 하나 이상의 당사자에 영향을 끼치므로 서로 조율해서 컨트랙트를 정의해야 함
• 협력형 패턴 그룹
  • 단일 팀에 의해 구현된 바운디드 컨텍스트
  • 한 팀의 성공이 다른 팀의 성공에 달려있고, 그 반대도 마찬가지인 의존적 목표가 있는 팀에 해당됨
  • 파트너십 패턴
    • 파트너십 모델에서 바운디드 컨텍스트 간의 연동은 애드혹(ad-hoc) 방식으로 조정함. 한 팀은 다른 팀에게 API의 변경을 알리고 다른 팀은 충돌 없이 이를 받아들임
• 사용자-제공자 패턴 그룹
  • 제공자는 사용자에게 서비스를 제공함. 서비스 제공자는 업스트림이고 고객 또는 사용자는 다운스트림이다
  • 양 팀(업스트림과 다운스트림)은 서로 독립적으로 성공할 수 있음. 업스트림 또는 다운스트림의 팀이 연동 컨트랙트를 주도하는 권력의 불균형이 존재함.
  • 힘의 차이를 보여주는 세 가지 패턴
    • 순응주의자 패턴
      • 힘의 균형이 서비스를 제공하는 업스트림 팀에 있는 경우가 있음. 사용자의 요구를 지원할 동기가 없는 경우가 그렇다.
      • 다운스트림 팀이 업스트림 팀의 모델을 받아들이는 바운디드 컨텍스트의 관계를 순응주의자(conformist) 패턴
    • 충돌 방지 계층 패턴
      • 순응주의자 패턴에서 힘의 균형은 업스트림 서비스에 치우쳐 있음
      • 다운스트림 바운디드 컨텍스트가 이에 순응하지 않는 경우 표현한 충돌 방지 계층을 통해 업스트림 바운디드 컨텍스트의 모델을 스스로의 필요에 맞게 가공할 수 있음
      • 다운스트림 바운디드 컨텍스트가 핵심 하위 도메인을 포함할 경우
        • 핵심 하위 도메인은 각별한 주의가 필요함. 제공자의 모델이 자칫 문제 도메인에 대한 모델링을 방해할 수 있음
      • 업스트림 모델이 사용자의 요건에 비효율적이거나 불편한 경우
        • 바운디드 컨텍스트가 혼란에 순응하면 그 자체로 위험에 빠지게 됨. 이런 경우는 레거시 시스템과 연동할 때 종종 발생함
      • 제공자가 컨트랙트를 자주 변경하는 경우
        • 사용자는 잦은 변경으로부터 모델을 보호하기를 원함. 충돌 방지 계층이 있으면 제공 모델의 변경은 변환 장치에만 영향을 미침
    • 오픈 호스트 서비스 패턴
      • 힘이 사용자 측에 있을 경우를 처리함. 제공자는 사용자를 보호하고 가능한 최고의 서비스를 제공하는 데 관심이 있음
      • 오픈 호스트 서비스(OHS: open-host service) 패턴은 충돌 방지 계층 패턴의 반대. 사용자 대신 제공자가 내부 모델 번역을 구현함
• 분리형 노션(separated ways)
  • 분리형 노션 패턴에는 팀에 협업 의지가 없거나 협업할 수 없는 경우와 같이 다양한 이유가 있음
  • 커뮤니케이션 이슈
  • 일반 하위 도메인
    • 중복된 하위 도메인의 특성도 협업 없이 분리된 길을 가야 하는 이유가 될 수 있음
  • 모델의 차이
    • 바운디드 컨텍스트의 모델 간의 차이
• 컨텍스트 맵
  • 컨텍스트 맵은 시스템의 바운디드 컨텍스트와의 연동을 시각적으로 표현함
  • 거시적 설계 관점
    • 컨텍스트 맵은 시스템의 구성요소와 구현하는 모델의 개요를 제공함
  • 커뮤니케이션 패턴
    • 컨텍스트 맵은 시스템의 구성요소 간의 커뮤니케이션 패턴을 묘사함. 예를 들어 어떤 팀이 협력하고, 충돌 방지 계층과 분리형 노선 패턴과 같은 덜 친밀한 연동 패턴을 선호하는지 보여줌
  • 조직적 문제
    • 컨텍스트 맵은 조직적 문제에 대한 통찰력을 제공함. 가령 특정 업스트림 팀의 다운스트림 사용자가 모두 충돌 방지 계층을 구현하는 데 의존하거나 분리형 노선 패턴의 모든 구현이 한 팀에 집중된다면 이는 무엇을 의미할까?
• 바운디드 컨텍스트가 연동하는 다양한 방법
  • 파트너십 : 바운디드 컨텍스트는 애드혹 방식으로 연동됨
  • 공유 커널 : 두 개 이상의 바운디드 컨텍스트가 참여하는 모든 바운디드 컨텍스트가 공유하는 제한적으로 겹치는 모델을 공유해서 연동함
  • 순응주의자 : 사용자는 서비스 제공자의 모델에 순응함
  • 충돌 방지 계층 : 사용자는 서비스 제공자의 모델을 사용자의 요건에 맞게 번역함
  • 오픈 호스트 서비스 : 서비스 제공자는 사용자의 요건에 최적화된 모델인 공표된 언어를 구현함
  • 분리형 노선 : 협력과 연동보다는 특정 기능을 중복으로 두는 것이 더 저렴한 경우

전술적 설계

간단한 비즈니스 로직 구현

• 트랜잭션 스크립트
  • 이 패턴은 시스템 작업을 간단하고 쉬운 절차지향 스크립트로 구성함. 이 절차는 작업에 트랜잭션을 적용해서 작업이 성공하거나 실패하도록 보장함. 트랜잭션 스크립트 패턴은 ETL처럼 단순한 비즈니스 로직을 가진 지원 하위 도메인에 적합함
  • 트랜잭션 스크립트 패턴은 프로시저를 기반으로 시스템의 비즈니스 로직을 구성하며, 각 프로시저는 퍼블릭 인터페이스를 통해 시스템 사용자가 실행하는 작업을 구현함
  • 구현
    • 각 프로시저는 간단하고 쉬운 절차지향 스크립트(procedural script, 객체지향 언어와 대비되는 개념으로 ,절차지향은 순차적인 처리가 중요시되는 스크립트)로 구현함
    • 가장 곤란한 순간에 트랜잭션 스크립트 실행이 실패하더라도 시스템은 오류가 발생할 때까지 변경사항을 롤백하거나 보상조치를 실행하여 일관성을 유지해야 함
  • 트랜잭션 동작 구현 실패
    • 트랜잭션 동작 구현에 실패한 간단한 예는 전체를 아우르는 트랜잭션 없이 여러 업데이트를 하는 경우
    • 만약 Users 테이블에 레코드가 업데이트되고 나서 로그 레코드를 성공적으로 추가하기 전에 문제가 발생한다면 시스템이 일관되지 않은 상태가 됨. Users 테이블은 업데이트되지만 VisitLog 테이블에는 해당 레코드가 기록되지 않음. 이 문제는 네트워크 중단, 데이터베이스 시간 초과 또는 교착 상태, 프로세스를 실행하는 서버의 충돌로도 발생할 수 있음
  • 분산 트랜잭션
    • 최신 분산 시스템에서는 데이터베이스의 데이터를 변경한 다음 메시지 버스에 메시지를 발행하여 시스템의 다른 컴포넌트에 변경사항을 알리는 것이 일반적
    • 여러 저장 장치에 걸쳐 있는 분산 트랜잭션은 복잡하고 확장하기 어렵고 오류가 발생하기 쉬우므로 일반적으로 피하는 방식
    • 트랜잭션 동작을 보장하는 한 가지 방법은 작업을 멱등성(idempotent)으로 만드는 것. 같은 요청을 여러 번 반복하더라도 그 결과는 매번 동일하게 만드는 것
    • 낙관적 동시성 제어(optimistic concurrency control)를 사용하는 것
  • 트랜잭션 스크립트를 사용하는 경우
    • 트랜잭션 스크립트 패턴은 비즈니스 로직이 단순한 절차적 작업처럼 매우 간단한 문제 도메인에 효과적
    • 트랜잭션 스크립트 패턴의 주요 장점은 단순함. 최소한의 추상화를 도입하여 런타임 성능을 최적화하고, 비즈니스 로직을 이해하기 위한 시간을 최소화함
    • 비즈니스 로직이 복잡할수록 트랜잭션 간에 비즈니스 로직이 중복되기 쉽고 결과적으로 중복된 코드가 동기화되지 않을 때 일관성 없는 동작이 발생함. 결과적으로 핵심 하위 도메인에는 트랜잭션 스크립트를 사용하면 안됨
• 액티브 레코드
  • 비즈니스 로직이 단순하지만 복잡한 자료구조에서 작동하는 경우 해당 자료구조를 액티브 레코드로 구현할 수 있음. 액티브 레코드 객체는 간단한 CRUD 데이터 접근 방법을 제공하는 자료구조
  • 트랜잭션 스크립트 패턴과 마찬가지로 액티브 레코드는 비즈니스 로직이 단순한 경우 사용함. 액티브 레코드는 좀 더 복잡한 자료구조에서도 비즈니스 로직이 작동할 수 있음
  • 구현
    • 액티브 레코드 객체는 객체 관계 매핑(ORM:object-relational mapping) 또는 다른 데이터 접근 프레임워크와도 관련이 있음. 각 자료구조가 액티브(active)하다는 점에서 패턴의 이름이 만들어졌음. 액티브 레코드는 데이터 접근 로직을 구현함
    • 액티브 레코드의 경우 데이터베이스에 직접 접근하는 대신 트랜잭션 스크립트가 액티브 레코드 객체를 조작한다는 것. 작업이 완료되면 트랜잭션의 원자성(atmoic)으로 인해 작업이 성공하거나 실패함
  • 액티브 레코드를 사용하는 경우
    • 액티브 레코드는 본질적으로 데이터베이스에 대한 접근을 최적화하는 트랜잭션 스크립트이기 때문에 사용자 입력의 유효성을 검사하는 CRUD 작업과 같은 비교적 간단한 비즈니스 로직만 지원할 수 있음
    • 트랜잭션 스크립트 패턴과 마찬가지로 액티브 레코드 패턴은 지원 하위 도메인, 일반 하위 도메인과 외부 솔루션의 연동, 모델 변환 작업에 적함함. 두 패턴의 차이점은 액티브 레코드의 경우 복잡한 자료구조를 데이터베이스 스키마에 매핑하는 복잡성을 해소한다는 것
    • 빈약한 도메인 모델 안티패턴(anemic domain model antipattern). 부적절하게 설계된 도메인 모델

복잡한 비즈니스 로직 다루기

• 도메인 모델
  • 도메인 모델 패턴은 복잡한 비즈니스 로직을 다루기 위한 것. CRUD 인터페이스 대신 복잡한 상태 전환, 항상 보호해야 하는 규칙인 비즈니스 규칙과 불변성을 다룸
  • SLA(응답 제한 시간)
  • 구현
    • 도메인 모델은 행동과 데이터 모두를 포함하는 도메인의 객체 모델. DDD의 전술 패턴인 애그리게이트, 밸류 오브젝트, 도메인 이벤트, 도메인 서비스는 모두 객체 모델의 구성요소
  • 밸류 오브젝트
    • 값만으로 식별되는 비즈니스 도메인의 개념이기 때문에 명시적인 ID 필드가 필요없음. 필드 중 하나가 변경되면 의미상 새로운 값을 생성하므로 밸류 오브젝트는 불변임
    • 색처럼 복합적인 값에 의해 식별되는 객체
    • 필드 중 하나의 값이 바뀌면 새로운 색이 탄생함. 같은 값을 갖는 두 개 이상의 색은 존재하지 않음. 같은 색의 두 인스턴스는 반드시 같은 값을 갖음
    • 밸류 오브젝트를 사용하는 경우
      • 밸류 오브젝트는 가능한 모든 경우에 사용하는 게 좋음. 밸류 오브젝트는 코드의 표현력을 높여주고 분산되기 쉬운 비즈니스 로직을 한데 묶어줄 뿐만 아니라 코드를 더욱 안전하게 해줌. 밸류 오브젝트는 불변이기 때문에 내포된 동작은 부작용과 동시성 문제가 없음
      • 경험상 비즈니스 도메인 관점에서 유용한 법칙은 다른 객체의 속성을 표현하는 도메인의 요소에 밸류 오브젝트를 사용하는 것
  • 엔티티
    • 엔티티는 다른 엔티티 인스턴스와 구별하기 위해 명시적인 식별 필드가 필요함
    • 밸류 오브젝트와는 반대로, 엔티티는 불변이 아니고 변할 것으로 예상됨. 밸류 오브젝트는 엔티티의 속성을 설명한다는 것
    • 엔티티는 모든 비즈니스 도메인의 필수 구성 요소
  • 애그리게이트
    • 트랜잭션 경계를 공유하는 엔티티의 계층. 애그리게이트의 경계에 속하는 모든 데이터는 비즈니스 로직의 구현을 통해 강력한 일관성을 유지해야 함
    • 애그리게이트는 엔티티. 명시적인 식별 필드가 필요하고 인스턴스의 생애주기 동안 상태가 변할 것으로 예상됨
  • 도메인 이벤트
    • 도메인 이벤트는 비즈니스 도메인에서 일어나는 중요한 이벤트를 설명하는 메시지
      • 티켓이 할당됨
      • 티켓이 상부에 보고됨
      • 메시지가 수신됨
  • 유비쿼터스 언어
    • 애그리게이트는 유비쿼터스 언어를 사용해야 함. 애그리게이트의 이름, 데이터 멤버, 동작 그리고 도메인 이벤트에 사용된 모든 용어는 모두 바운디드 컨텍스트의 유비쿼터스 언어로 명명돼야 함
  • 도메인 서비스
    • 도메인 모델에서 애그리게이트 또는 밸류 오브젝트에 속하지 않는 비즈니스 로직을 담는 상태가 없는 객체
    • 비즈니스 로직을 구현할 상태가 없는 객체(stateless object)
    • 이런 로직은 어떤 계산이나 분석을 수행하기 위한 다양한 시스템 구성요소의 호출을 조율함

시간 차원의 모델링

• 이벤트 소싱
  • 이벤트 소싱 패턴은 데이터 모델에 시간 차원을 도입함. 애그리게이트의 현재 상태를 반영하는 스키마 대신 이벤트 소싱 기반 시스템은 애그리게이트의 수명주기의 모든 변경사항을 문서화하는 이벤트를 유지함
  • 프로젝션 - 이벤트 소싱 패턴에서 쓰기 모델을 통해 이벤트 소싱 시스템에 이력 형태로 저장된 데이터를 다양한 읽기 모델을 적용해 원하는 시점의 데이터를 추출하는 기법
• 원천 데이터
  • 이벤트 소싱 패턴이 작동하려면 객체 상태에 ㄷ대한 모든 변경사항이 이벤트로 표현되고 저장되어야 함
  • 이벤트는 시스템의 원천 데이터가 됨
  • 시스템의 이벤트를 저장하는 데이터베이스는 유일하고 강력하게 일관된 저장소인 시스템의 원천 데이터. 이벤트를 저장하는 데 사용되는 데이터베이스를 지칭하는 이름이 이벤트 스토어(event store)
  • 리하이드레이션 : 데이터 또는 파일 등에 액세스할 수 있게 재구성 또는 복원하는 작업
  • 이벤트 스토어
    • 이벤트 스토어는 추가만 가능한 저장소이므로 이벤트를 수정하거나 삭제할 수 없음
    • 특정 비즈니스 엔티티에 속한 모든 이벤트를 가져오고 이벤트를 추가하는 것
• 이벤트 소싱 도메인 모델
  • 이벤트 소싱 애그리게이트에 대한 각 작업의 단계
    • 애그리게이트의 도메인 이벤트를 로드함
    • 이벤트를 비즈니스 의사결정을 내리는 데 사용할 수 있는 상태로 프로젝션해서 상태 표현을 재구성함
    • 애그리게이트의 명령을 실행하여 비즈니스 로직을 실행하고 결과적으로 새로운 도메인 이벤트를 생성함
    • 새 도메인 이벤트를 이벤트 스토어에 커밋함
  • 이벤트 소싱 애그리게이트로 구현하는 방법
    • 관련 티켓의 이벤트를 로드하고, 애그리게이트 인스턴스를 리하이드레이션하고, 관련 명령을 호출하고, 변경사항을 데이터베이스에 다시 저장함
  • 장점
    • 시간 여행
      • 도메인 이벤트를 사용하여 애그리게이트의 현재 상태를 재구성할 수 있는 것처럼 도메인 이벤트는 애그리게이트의 모든 과거 상태를 복원하는 데도 사용할 수 잇음. 애그리게이트의 모든 과거 상태를 필요할 때 언제든 재구성할 수 있음
      • 시간 여행은 시스템의 동작을 분석하고, 시스템의 의사결정을 검사하고, 비즈니스 로직을 최적화할 때 종종 필요함
    • 심오한 통찰력
      • 이벤트 소싱은 시스템의 상태와 동작에 대한 깊은 통찰력을 제공함
    • 감사 로그
      • 영속적인 도메인 이벤트는 애그리게이트 상태에 발생한 모든 것에 대한 강력하게 일관된 감사 로그(audit log)를 나타냄. 법률에 따라 일부 비즈니스 도메인은 이러한 감사 로그를 반드시 구현해야 하며 이벤트 소싱은 이를 즉시 제공함
      • 이 모델은 화폐 또는 금전 거래를 관리하는 시스템에 잘 이용됨. 이를 통해 시스템의 의사결정과 계정 간의 자금 흐름을 쉽게 추적할 수 있음
    • 고급 낙관적 동시서 제어
      • 고급 낙관적 동시성 모델은 읽기 데이터가 기록되는 동안 다른 프로세스의 의해 덮여 쓰여지는 경우 예외를 발생시킴
      • 이벤트 소싱을 사용할 때 기존 이벤트를 읽고 새 이벤트를 작성하는 사이에 정확히 무슨 일이 일어났는지 더 깊은 통찰력을 얻을 수 있음
  • 단점
    • 학습 곡선
      • 패턴인 데이터를 관리하는 기존 기술과 엄청난 차이가 있다는 것은 명백한 단점
    • 모델의 진화
      • 이벤트 소싱 모델을 발전시키는 것은 어려울 수 있음. 이벤트 소싱의 정의를 엄밀하게 따지면 이벤트는 변경할 수 없음
    • 아키텍처 복잡성
      • 이벤트 소싱을 구현하면 수많은 아키텍처의 유동적인 부분이 도입되어 전체 설계가 더 복잡해짐
• 샤딩 : 대량의 데이터를 처리하기 위해 데이터베이스 테이블을 분할하여 물리적으로 서로 다른 곳에 분산 저장 및 조회하는 것

아키텍처 패턴

• 비즈니스 로직과 아키텍처 패턴
  • 아키텍처 패턴은 코드베이스의 다양한 측면에 대한 구성 원칙을 도입하고 이들 사이의 명확한 경계를 제시함. 비즈니스 로직이 어떻게 시스템의 입력과 출력, 그리고 다른 기반 구성요소와 연결되는가와 같은 것이 코드베이스의 다양한 측면 중 하나
• 계층형 아키텍처(layered architecture)
  • 가장 일반적인 아키텍처 패턴 중 하나. 코드베이스를 수평 계층으로 조직하고, 각 계층은 사용자와 상호작용, 비즈니스 로직의 구현, 그리고 데이터의 저장과 같은 기술적 관심사 중 하나를 다룸
  • 고전적인 형태의 계층형 아키텍처는 프레젠테이션 계층(PL), 비즈니스 로직 계층(BLL), 데이터 접근 계층(DAL)의 세 가지 계층으로 구성 됨
  • 프레젠테이션 계층
    • 사용자와 상호작용을 하기 위한 프로그램의 사용자 인터페이스를 구현함
    • 현대 시스템에서 프레젠테이션 계층은 프로그램의 동작을 촉발하는 모든 동기식 또는 비동기식 수단과 같은 좀 더 광범위한 범주를 포함함
      • 그래픽 사용자 인터페이스(GUI)
      • 커맨드 라인 인터페이스(CLI)
      • 다른 시스템과 연동하는 프로그래밍 API
      • 메시지 브로커에서 이벤트에 대한 구독
      • 나가는 이벤트를 발행하는 메시지 토픽
    • 프레젠테이션 계층은 프로그램의 퍼블릭 인터페이스
  • 비즈니스 로직 계층
    • 프로그램의 비즈니스 로직을 구현하고 묶는 것을 담당함. 비즈니스 의사결정을 구현함
  • 데이터 접근 계층
    • 영속성 메커니즘에 접근할 수 있게 해줌. 원래 패턴에서는 이 계층이 시스템의 데이터베이스를 가리킴
    • 혁신적인 NoSQL이 출현한 이래로 여러 데이터베이스를 사용하는 시스템이 보편화됐음. 도규먼트 저장소는 실시간 데이터 처리 데이터베이스의 역할을 하고 검색 인덱스는 동적 질의에 쓰이며, 인메모리 데이터베이스는 최적화된 성능을 내는 동작에 활용됨
    • 정보 저장용으로 전통적인 데이터베이스뿐만 아니라 다양한 매체가 있음. 클라우드 기반 오브젝트 저장소는 시스템의 파일을 저장할 수 있고, 메시지 버스는 프로그램의 다양한 기능의 커뮤니케이션을 조율하는 데 쓰임
    • 프로그램의 기능을 구현하는 데 필요한 다양한 외부 정보 제공자와 연동하는 것을 포함함
• 계층 간 커뮤니케이션
  • 계층은 톱다운 커뮤니케이션 모델에 따라 연동함. 각 계층은 바로 아래 계층에만 의존함. 구현 관심사의 결합성을 낮추고 계층 간에 공유할 지식을 줄임
• 변종(variation)
  • 서비스 계층
    • 서비스 계층은 프로그램의 프로젠테이션 계층과 비즈니스 로직 계층 사이의 중간 역할을 함
    • 서비스 계층을 명시적으로 갖추면 몇 가지 장점
      • 동일한 서비스 계층을 여러 퍼블릭 인터페이스에서 재사용할 수 있음. 예를 들어, 그래픽 유저 인터페이스와 API 등. 중복된 조율 로직이 필요 없게 됨
      • 모든 관련 메서드를 한곳에 모으면 모듈화가 개선됨
      • 프레젠테이션 계층과 비즈니스 로직 계층의 결합도를 낮춤
      • 비즈니스 기능을 테스트하기 쉬워짐
  • 용어
    • 프레젠테이션 계층 = 사용자 인터페이스 계층
    • 서비스 계층 = 애플리케이션 계층
    • 비즈니스 로직 계층 = 도메인 계층 = 모델 계층
    • 데이터 접근 계층 = 인프라스트럭처 계층
• 의존성 역전 원칙(DIP: dependency inversion principle)
  • 비즈니스 로직을 구현하는 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 됨
• 인프라 구성요소의 연동
  • 포트와 어댑터 아키텍처의 핵심 목적은 인프라스트럭처 구성요소로부터 시스템의 비즈니스 로직을 분리하는 것
  • 인프라스트럭처 구성요소를 직접 참조하고 호출하는 대신, 비즈니스 로직 계층은 인프라스트럭처 계층이 구현해야 할 포트를 정의함. 인프라스트럭처 계층은 어댑터를 구현함
• 변형
  • 포트와 어댑터 아키텍처는 헥사고날 아키텍처, 어니언 아키텍처, 그리고 클린 아키텍처로 알려져 있음
  • 애플리케이션 계층 = 서비스 계층 = 유스케이스 계층
  • 비즈니스 로직 계층 = 도메인 계층 = 핵심 계층
• CQRS(command-query responsibility segregation)
  • 포트와 어댑터에 동일한 비즈니스 로직과 인프라스트럭처 관심사에 기반함. 시스템의 데이터를 관리하는 방식이 다름. 이 패턴을 사용하면 여러 영속 모델에 시스템의 데이터를 표현할 수 있음
  • 커맨드 실행 모델
    • CQRS에는 시스템의 상태를 수정하는 오퍼레이션(시스템 커맨드)을 전담으로 수행하는 단일 모델이 있음
    • 커맨드 실행 모델은 시스템의 원천인 강력한 일관성을 가진 데이터를 표현하는 유일한 모델. 비즈니스 엔티티의 일관적 상태를 읽을 수 있어야 하고 갱신할 때 낙관적 동시성을 지원해야 함
  • 읽기 모델(프로젝션)
    • 읽기 모델은 캐시에서 언제든 다시 추출할 수 있는 프로젝션. 이는 견고한 데이터베이스, 일반 파일 또는 인메모리 캐시에 위치할 수 있음
  • CQRS를 사용해야 하는 경우
    • CQRS 패턴은 여러 모델, 궁극적으로 다양한 종류의 데이터베이스에 저장된 동일한 데이터와 작동할 필요가 있는 애플리케이션에 유용함
    • 인프라스트럭처 관점에서는 CQRS가 다양한 종류의 데이터베이스의 장점을 활용할 수 있게 해줌. 예를 들어, 커맨드 실행 모델을 저장을 위한 관계형 데이터 베이스, 전문 검색을 위한 검색 인덱스, 빠른 데이터 검색을 위한 사전 렌더링된 플랫 파일 등이 있으며, 이러한 모든 스토리지 메커니즘이 신뢰성 있게 동기화 됨
    • CQRS는 이벤트 소싱 도메인 모델에도 적합함. 이벤트 소싱 모델에서는 애그리게이트의 상태에 기반한 레코드 조회가 불가능하지만 CQRS는 상태를 질의할 수 있는 데이터베이스에 상태를 프로젝션하므로 이것이 가능함
• 계층형 아키텍처는 기술적 관심사에 따라 코드베이스를 분해함. 비즈니스 로직과 데이터 접근 구현을 결합시키므로 액티브 레코드 기반 시스템에 적합함
• 포트와 어댑터 아키텍처는 관계를 역전 시킴. 비즈니스 로직을 중심에 두고 모든 인프라스트럭처와의 의존성을 분리함. 이 패턴은 도메인 모델 패턴을 구현하는 비즈니스 로직에 적합함
• CQRS 패턴은 여러 모델에서 동일한 데이터를 표현함. 이 패턴은 이벤트 소싱 도메인 모델에 기반한 시스템에 적합하지만 다양한 영속 모델을 사용할 필요가 있는 어떤 시스템에도 사용할 수 있음

커뮤니케이션 패턴

• 모델 변환
  • 상태를 보존하지 않는 스테이트리스 변환(stateless translation)은 수신(OHS) 또는 발신(ACL) 요청이 발행할 때 즉석에서 발생하는 반면, 스테이트풀 변환(stateful translation)은 상태 보존을 위해 데이터베이스를 사용하여 좀 더 복잡한 변환 로직을 다룰 수 있음
• 아웃박스 패턴은 애그리게이트의 도메인 이벤트를 발행하는 안정적인 방법. 다른 프로세스 실패에 직면해도 도메인 이벤트를 항상 발행함
• 사가 패턴은 간단한 교차 컴포넌트 비즈니스 프로세스를 구현하는 데 사용할 수 있음. 프로세스 관리자 패턴을 사용하여 좀 더 복잡한 비즈니스 프로세스를 구현할 수 있음. 두 패턴 모두 도메인 이벤트에 대한 비동기식 반응과 커맨드 실행에 의존함

도메인 주도 설계 적용 실무

휴리스틱 설계

• 테스트 전략
  • 피라미드형 테스트
    • 고전적인 피라미드형 테스트 전략에서는 단위 테스트를 강조하고 통합 테스트는 별로 없으며, 엔드-투-엔드 테스트는 더더욱 없음
    • 피라미드형 테스트는 애그리게이트와 밸류 오브젝트 도메인 모델 패턴을 모두 잘 지원함. 두 도메인 모델 패턴은 모두 사실상 비즈니스 로직을 테스트하는 완벽한 단위
  • 다이아몬드형 테스트
    • 다이아몬드형 테스트에서 가장 집중하는 유형은 통합 테스트
    • 액티브 레코드 패턴이 사용되면 시스템의 비즈니스 로직은 서비스 계층과 비즈니스 로직 계층에 흩어지므로 두 계층의 연동에 중점을 둔다면 다이아몬드형 테스트가 더 효과적인 선택
  • 역전된 피라미드형 테스트
    • 엔드-투-엔드 테스트에 가장 많이 집중함
    • 처음부터 끝까지 애플리케이션 워크플로를 검증하는 것. 이 같은 접근 방법은 트랜잭션 스크립트 패턴을 구현한 코드베이스에 가장 잘 어울림

진화하는 설계 의사결정

• 성장
  • 많은 도메인 주도 설계 도구가 비즈니스 구성요소(하위 도메인), 모델(바운디드 컨텍스트), 불변성(밸류 오브젝트), 일관성(애그리게이트)과 같은 경계 설정에 관한 것이기 때문에 성장이 설계 의사결정에 미치는 영향을 조사하는 것이 중요함
  • 하위 도메인
    • 하위 도메인을 통해 다양한 비즈니스 가치의 구성요소를 식별하고 적절한 도구를 사용해서 솔루션을 설계하고 구현할 수 있어야 함
  • 바운디드 컨텍스트
    • 특정 문제를 해결하는 데 초점을 맞춘 바운디드 컨텍스트를 추출하여 모델을 단순화할 수 있는 기회를 항상 찾아라
  • 애그리게이트
    • 경험상 애그리게이트는 가능한 한 작게 유지하고, 비즈니스 도메인에서 강력하게 일관적인 상태를 유지해야 하는 객체만 포함함

이벤트스토밍

• 로우테크(low-tech, 간단한 도구 또는 적은 비용으로 빠르고 쉽게 반복 수행하여 목적을 달성하는 접근법) 모델링 과정인 이벤트스토밍(EventStorming)에 집중함
• 이벤트스토밍
  • 이벤트스토밍은 사람들이 모여 비즈니스 프로세스에 관해 브레인스토밍하고 신속하게 모델링하기 위한 로우테크 활동
  • 이벤트스토밍에는 범주(scope), 즉 참가자가 다룰 비즈니스 프로세스가 있음
• 이벤트스토밍에 무엇이 필요한가?
  • 모델링 공간
  • 포스트잇
  • 마커
  • 간식
  • 회의실
• 이벤트스토밍 과정
  • 1단계: 자유로운 탐색 - 이벤트스토밍은 탐색하려는 비즈니스 도메인에 관련된 도메인 이벤트를 브레인스토밍하는 것으로 시작함
  • 2단계: 타임라인 - 참가자는 생성된 도메인 이벤트를 읽어보고 그것을 비즈니스 도메인에서 발생하는 순서대로 정리함
  • 3단계: 고충점 - 일단 시간 순서대로 이벤트를 구성했으면 전체 구성을 보고 프로세스에 주목할 만한 포인트를 식별함. 예를 들어 병목구간, 자동화가 필요한 수작업 단계, 문서가 사라졌거나 도메인 지식이 없는 경우
  • 4단계: 중요 이벤트 - 일단 이벤트 타임라인에 고충점을 기록했으면 컨텍스트나 국면이 바뀌는 것을 나타내는 중요한 비즈니스 이벤트를 찾음. 이를 중요 이벤트(pivotal event)라고 하며, 이 이벤트는 전후로 세로로 선을 긋는다
  • 5단계: 커맨드 - 도메인 이벤트가 이미 발생한 것을 설명하는 반면, 커맨드는 무엇이 이벤트 또는 이벤트의 흐름을 시작하게 하는지를 설명함
  • 6단계: 정책 - 자동화 정책은 이벤트가 커맨드의 실행을 시작하는 시나리오. 커맨드는 특정 도메인 이벤트가 발생할 때 자동으로 실행됨
  • 7단계: 읽기 모델 - 읽기 모델은 도메인에서 액터카 커맨드를 실행하는 의사결정을 내릴 때 사용하는 시각적 데이터. 시스템에 스크린, 리포트, 알림 등이 될 수 있음
  • 8단계: 외부 시스템
  • 9단계: 애그리게이트 - 일단 모든 이벤트와 커맨드가 표현되면 참가자는 애그리게이트의 개념을 포함하여 모델을 구성할 수 있음. 애그리게이트는 커맨드를 받고 이벤트를 생성함
  • 10단계: 바운디드 컨텍스트 - 이벤트스토밍 세션의 마지막 단계에서는 서로 연관된 애그리게으트를 찾음
• 이벤트스토밍을 사용하는 경우
  • 유비쿼터스 언어 구축하기
  • 비즈니스 프로세스 모델링하기
  • 새로운 비즈니스 요구사항 탐색하기
  • 도메인 지식 복구하기
  • 존재하는 비즈니스 프로세스의 개선 방법 탐색하기
  • 새로운 팀원의 훈련

실무에서의 도메인 주도 설계

• DDD의 혜택을 가장 많이 받을 수 있는 프로젝트는 브라운필드 프로젝트. 이미 비즈니스 가능성을 입증했고 축적된 기술 부채와 설계 엔트로피에 맞서 대대적인 변화가 필요한 프로젝트를 말함
• 현대화 전략
  • 시스템의 모듈을 조정하는 것은 비교적 안전한 형태의 리팩터링. 비즈니스 로직을 수정하는 것이 아니라, 단지 더 잘 구성된 구조로 유형을 재배치 하는 것. 즉, 라이브러리의 동적 로딩, 리플렉션 등과 같은 전체 타입명에 의한 참조가 끊어지지 않게 해야 함
  • 데이터베이스의 저장 프로시저, 서버리스 함수 등 다른 코드베이스에서 구현된 하위 도메인의 비즈니스 로직을 관리함
  • 전략적 현대화
    • 사용자-제공자 관계 : 적절한 유형의 사용자-제공자 관계(순응주의자나 충돌 방지 계층, 오픈 호스트 서비스)로 리팩터링 해라
    • 충돌 방지 계층 : 충돌 방지 계층은 특히 레거시 시스템이 다운스트림 컴포넌트로 확산되는 경향이 있는 비효율적인 모델을 사용하는 경우 레거시 시스템에서 바운디드 컨텍스트를 보호하는 데 유용함
    • 오픈 호스트 서비스 : 한 컴포넌트의 구현 상세에 대한 변경사항이 시스템을 통해 자주 파문을 일으켜 사용자에게 영향을 미치는 경우 이를 오픈 호스트 서비스로 만드는 것을 고려하라
    • 분리형 노선 : 특히 대기업에서는 공유 기능을 공동으로 발전시키고 공동 개발해야 하므로 엔지니어링 팀 간에 마찰이 발생할 수 있음. 불화의 씨앗이 되는 기능이 비즈니스에 중요하지 않은 경우(즉 핵심 하위 도메인이 아닌 경우) 팀은 분리형 노선 패턴을 적용해 자체 솔루션을 구현하면 마찰의 원인을 제거할 수 있음

다른 방법론 및 패턴과의 관계

마이크로서비스

• 마이크로서비스는 빠르게 바뀌고, 확장되며, 클라우드 컴퓨팅의 특성에 맞춰야 하는 현대 시스템의 요구사항을 해결하는 것
• 마이크로서비스
  • 서비스가 자신의 퍼블릭 인터페이스에 의해 정의되므로 마이크로서비스는 자신의 마이크로 퍼블릭 인터페이스, 즉 마이크로 프런트 도어(micro-fron door)에 의해 정의되느 서비스
  • 마이크로 퍼블릭 인터페이스가 있으면 단일 서비스의 기능과 그 서비스가 연동하는 다른 시스템 구성요소 모두를 쉽게 이해할 수 있음. 서비스의 기능을 줄이면 변경될 이유가 줄어들고 개발, 관리, 확장을 자율적으로 할 수 있음
• 도메인 주도 설계와 마이크로서비스 경계
  • 바운디드 컨텍스트
    • 마이크로서비스와 바운디드 컨텍스트 모두 물리적 경계. 바운디드 컨텍스트와 마찬가지로 마이크로서비스도 단일 팀이 소유함
      • 바운디드 컨텍스트와 동일하게, 충돌하는 모델은 인터페이스가 복잡해지므로 마이크로서비스로 구현할 수 없음
    • 바운디드 컨텍스트는 유비쿼터스 언어와 모델의 일관성을 보호함. 충돌하는 모델은 동일한 바운디드 컨텍스트에 구현할 수 없음
    • 마이크로서비스와 바운디드 컨텍스트의 관계는 비대칭. 마이크로서비스 바운디드 컨텍스트로 볼 수 있지만, 모든 바운디드 컨텍스트가 마이크로 서비스인 것은 아님. 한편 바운디드 컨텍스트는 유효한 거대한 모놀리식의 경계를 표현함
• 기본적으로 마이크로서비스는 서비스의 가장 작은 유효한 경계를 정의하는 반면, 바운디드 컨텍스트는 모델 전반의 일관성을 보호하고 가장 넓은 유효한 경계를 나타냄

이벤트 주도 아키텍처(EDA: Event-Driven Architecture)

• 많은 사람이 느슨하게 결합되고, 확장 가능하며, 내결함성을 가진 분산 시스템을 설계할 때 이벤트 주도 커뮤니케이션을 기본 통합 메커니즘으로 사용할 것을 권고함
• 이벤트 주도 아키텍처
  • 시스템 컴포넌트가 이벤트 메시지를 교환하면서 비동기적으로 서로 커뮤니케이션하는 아키텍처 스타일
  • 이벤트 주도 아키텍처와 이벤트 소싱 모두 이벤트를 기반으로 하지만 EDA는 서비스 간 통신을 의미하는 반면, 이벤트 소싱은 서비스 내부에서 발생함. 이벤트 소싱을 위해 설계된 이벤트는 서비스에서 구현된(이벤트 소싱 도메인 모델의 애그리게이트) 상태 전환을 나타냄. 이는 비즈니스 도메인의 복잡성을 파악하기 위한 거싱며, 서비스를 다른 시스템 컴포넌트와 연동하기 위한 것이 아님
• 이벤트
  • 이벤트,커맨드,메시지
    • 이벤트(Event) : 이미 발생한 변화를 설명하는 메시지
    • 커맨드(Command) : 수행돼야 할 작업을 설명하는 메시지
    • 이벤트는 이미 일어난 일이고 커맨드는 어떤 일을 하라는 지시. 이벤트와 커맨드 모두 메시지로 비동기 통신할 수 있음. 그러나 커맨드는 거부될 수 있음
  • 이벤트 유형
    • 이벤트는 이벤트 알림, 이벤트를 통한 상태 전송, 도메인 이벤트의 세 가지 유형 중 하나로 분류할 수 있음
    • 이벤트 알림 : 이벤트 알림은 다른 컴포넌트가 반응할 비즈니스 도메인의 변경에 관한 메시지, 중요한 일이 발생했지만 사용자가 제공자에게 추가 정보를 명시적으로 질의해야 하는 알림
    • 이벤트를 통한 상태 전송(ECST:Event-Carried State Transfer) : 메시지는 구독자에게 제공자의 내부 상태에 대한 변경사항을 알려줌, 메시지 기반 데이터 복제 메커니즘, 각 이벤트에는 제공자의 데이터 로컬 캐시를 유지 관리하는 데 사용할 수 있는 스냅숏을 포함할 수 있음
    • 도메인 이벤트: 제공자의 비즈니스 도메인 내에서 발생하는 이벤트를 설명하는 메시지

데이터 메시

• 실시간 데이터 처리 시스템은 시스템의 데이터를 조작하고 시스템 환경에서 일어나는 이상적인 작업을 조율하는 실시간 트랜잭션을 구현함. 이 같은 모델이 OLTP 데이터다
• 분석 데이터 모델과 트랜잭션 데이터 모델의 비교
  • 분석 모델은 실시간 트랜잭션을 구현하는 대신 비즈니스 활동의 성과에 대한 통찰을 제공하는 것을 목표로 함. 더 많은 비즈니스 가치를 얻도록 운영을 최적화하는 방법을 제공하는 것이 목표라는 것
  • OLAP 모델은 개별 비즈니스 엔티티를 무시하는 대신 팩트 테이블과 디멘전 테이블을 모델링하여 비즈니스 활동에 집중함
  • 팩트 테이블
    • 이미 발생한 비즈니스 활동을 나타냄. 비즈니스 프로세스의 활동을 나타냄
    • 도메인 이벤트와 비슷하게 팩트 레코드는 절대로 삭제되거나 수정되지 않음. 분석 데이터는 추가만 가능한 데이터. 현재 데이터가 만료됐다는 것을 표현하는 유일한 방법은 새로운 레코드를 추가하는 것
    • OLAP와 OLTP 모델의 또 다른 큰 차이점은 데이터의 세분화 정도(granularity)
  • 디멘전 테이블
    • 팩트가 비즈니스 절차 또는 동작을 표현한다면(동사), 디멘전은 팩트를 묘사함(형용사). 디멘전은 팩트의 속성을 설명하도록 고안되어 팩트 테이블에 있는 외부 키로 디멘전 테이블을 참조함.
    • 디멘전으로 모델링된 속성은 다양한 팩트 레코드를 넘나들며 반복되는 모든 측정 또는 데이터이므로 단일 칼럼에는 맞지 않음
    • 디멘전이 고도로 정규화된 이유는 분석 시스템에서 유연한 질의를 지원해야 하기 때문. 이것이 바로 실시간 데이터 모델과 분석 모델의 또 다른 차이점
    • 정규화를 통해서 동적인 질의 및 필터링을 지원하고 다양한 디멘전에 걸친 팩트 데이터에 대한 그룹화를 지원함
  • 분석 모델
    • 스타 스키마. 팩트와 디멘전의 관계가 다대일(many-to-one). 각 디멘전의 레코드는 여러 팩트에서 사용됨. 단일 팩트의 외부 키들은 각기 하나의 디멘전 레코드를 가리킴
    • 스토우플레이크 스키마. 스노우플레이크 스키마는 동일하게 팩트와 디멘전으로 구성됨. 각 디멘전은 더 작은 세밀한 디멘전으로 ㅓㅇ규화됨
      • 추가적인 정규화로 인해 스노우플레이크 스키마는 더 작은 공간에 디멘전 데이터를 저장할 수 있고 유지보수가 쉬움. 팩트의 데이터를 조회할 때 더 많은 테이블을 조인해야 하므로 더 많은 컴퓨팅 자원이 필요함
• 분석 데이터 관리 플랫폼
  • 데이터 웨어하우스(DWH)
    • 기업의 모든 실시간 데이터 처리 시스템에서 데이터를 추출해서 분석 모델로 변환한 후에 분석 지향 데이터베이스(analysis-oriented database)에 적재함. 이를 데이터 웨어하우스
    • 데이터 관리 아키텍처는 기본적으로 ETL 스크립트를 기반으로 함. 데이터는 실시간 데이터 처리 데이터베이스, 스트림 이벤트(streaming event), 로그 등의 다양한 원천에서 수집됨
    • 원천 데이터를 팩트/디멘전 기반 모델로 변환하는 것과 더불어 변환 단계에서는 민감한 데이터를 제거하고 중복 레코드를 삭제하며, 이벤트의 순서 조정 및 작은 크기의 이벤트를 합치는 등의 추가적인 작업이 포함될 수 있음. 변환할 때 유입되는 데이터를 저장하기 위한 임시 저장소가 필요할 수 있음. 이 공간은 스테이징 영역으로 알려져 있음
    • 데이터 웨어하우스 아키텍처의 중심에는 엔터프라이즈 전반의 모델을 구축하는 목표가 있음. 모델은 기업의 모든 시스템에서 생성되는 데이터를 묘사하고, 다양한 분석 데이터의 사용 사례를 다뤄야 함. 예를 들어 분석 모델은 비즈니스 최적화, 운영 비용 절감, 지능적인 비즈니스 의사결정, 리포팅, 그리고 심지어 ML 모델 훈련까지 가능하게 함
    • 모든 상황을 아우르는 모델을 구축하는 것의 어려운 점은 데이터 마트를 사용하여 부분적으로 해결할 수 있음. 데이터 마트의 단일 비즈니스 부서의 분석과 같이, 잘 정의된 분석 요구사항에 관련된 데이터를 저장하는 일종의 데이터베이스
    • 데이터 마트 모델에서 어떤 마트는 ETL 프로세스가 실시간 데이터 처리 시스템으로부터 직접 추출되는 반면, 데이터 웨ㅓ하우스에서 데이터를 추출하는 마트도 있음
    • 데이터 웨어하우스 아키텍처의 다른 어려운 점음 ETL 프로세스가 분석(OLAP) 시스템과 실시간 데이터 처리(OLTP) 시스템 간에 강력한 결합을 만든다는 것. ETL 스크립트가 사용하는 데이터가 반드시 시스템의 퍼블릭 인터페이스를 노출될 필요는 없음
  • 데이터 레이크
    • 데이터 레이크 아키텍처는 실시간 데이터 처리 시스템의 데이터를 유입하고 분석 모델로 변환하는 동일한 개념에 기반함
    • 데이터 레이크 기반 시스템은 실시간 데이터 처리 시스템으로부터 데이터를 받음. 데이터를 바로 분석 모델로 변환하는 대신 원본 형태, 즉 원래의 실시간 데이터 모델로 보관함
    • 데이터 엔지니어와 BI 엔지니어는 데이터 레이크의 데이터를 이해하고 분석 모델을 생성하는 ETL 스크립트를 구현하며, 이를 데이터 웨하우스에 제공해야 함
    • 실시간 데이터 처리 시스템의 데이터는 원본 형태로 저장되고 나중에 변환되므로 데이터 레이크에서는 여러 가지 작업 지향 분석 모델을 작동시키는 것이 가능함
    • 분석 모델을 나중에 생성하게 되면 전체적인 시스템의 복잡성이 증가함
    • 데이터 레이크는 유입되는 데이터에 스키마를 강제하지 않는 무스키마이며, 수신 데이터의 품질을 제어하지 않음. 데이터 레이크는 특정 규모 이상이 되면 혼란스러워짐. 데이터 레이크를 사용하면 데이터를 쉽게 수집할 수 있지만 사용하기는 훨씬 더 어려움. 데이터 레이크가 데이터의 늪이 된다라고 이야기함
• 데이터 웨어하우스와 데이터 레이크 아키텍처의 도전과제
  • 데이터 메시
    • 데이터 메시 아키텍처는 분석 데이터를 위한 도메인 주도 설계
    • DDD에서 다양한 패턴이 경계를 긋고 내용을 프로젝션하듯이, 데이터 메시 아키텍처는 분석 데이터에 대한 모델과 소유 경계를 정의하고 프로젝션함
    • 데이터 메시 아키텍처는 도메인 기준의 데이터 분리, 제품 관점에서 데이터 다루기(data as a product), 자율성 활성화, 에코시스템의 구축의 네 가지 핵심 원칙을 기반으로 함
    • 도메인 기준의 데이터 분리
      • 데이터 메시 아키텍처는 모놀리식 분석 모델을 구축하는 대신, 실시간 데이터를 위한 솔루션, 즉 원천 데이터에 분석 모델을 일치시켜서 데이터를 사용하므로 여러 분석 모델을 사용할 수 있음.
      • 분석 모델의 소유권 경계를 자연스럽게 바운디드 컨텍스트의 경계와 일치시키게 됨
      • 각 바운디느 컨텍스트는 이제 자신의 실시간 데이터 처리 모델과 분석 모델을 소유함. 결과적으로 실시간 데이터 모델을 소유한 팀이 이제 그것을 분석 모델로 변환하는 책임을 짐
    • 제품 관점에서 데이터 다루기
      • 분석 시스템의 의심스러운 원천(내부 데이터베이스, 로그 파일 등)에서 실시간 데이터를 가져오게 하는 대신, 데이터 메시 기반 시스템에서는 바운디드 컨텍스트가 잘 정의된 출력 포트를 통해 분석 데이터를 제공함
      • 분석 데이터는 통상적인 퍼블릭 API와 동일하게 취급돼야 함
        • 필요한 엔드포인트인 데이터 출력 포트를 쉽게 찾을 수 있어야 함
        • 분석 엔드포인트는 제공하는 데이터와 형식을 설명하는 잘 정의된 스키마를 가져야 함
        • 분석 데이터는 신뢰할 수 있어야 하고 다른 API와 마찬가지로 서비스 수준 계약(SLA:service-level agreement)을 정의하고 모니터링 해야 함
        • 분석 모델은 일반적인 API처럼 버전 관리를 하고 그에 따라 모델에서 연동을 망가뜨리는 변경을 관리해야 함
      • 분석 데이터는 제품 관점에서 제공되므로 사용자의 요구를 반영해야 함. 데이터 메시는 데이터 웨어하우스 및 데이터 레이크 아키텍처와는 대조적으로 데이터 품질에 대한 책임이 가장 중요한 괌심사
      • 데이터 제품은 다양한 사용자의 요구사항을 충족하는 여러 형태의 데이터를 제공하도록 다양한 언어를 제공해야 함
    • 자율성 활성화
      • 플랫폼이 상호운용이 가능한 데이터 제품의 구축, 실행, 유지보수의 복잡성을 추상화할 필요가 있음
      • 데이터 인프라스트럭처 플랫폼 팀은 데이터 제품의 청사진, 단일화된 접근 패턴, 접근 제어, 그리고 제품 팀이 사용할 다양한 저장소를 정의해야 할 뿐만 아니라 플랫폼을 모니터링해서 SLA와 목적을 만족하는지 보장할 책임이 있음
    • 에코시스템 구축
      • 분석 데이터 도메인 관점에서 상호운용과 에코시스템을 가능하게 할 연합 거버넌스 기구를 임명하는 것
      • 거버넌스 그룹은 상호운용이 가능한 정상적인 에코시스템을 보장하는 규칙을 정의할 책임이 있음. 이 규칙은 모든 데이터 제품과 그 인터페이스에 적용돼야 하고, 거버넌스 그룹은 전사적으로 이 규칙을 따르고 보장할 책임이 있음
    • 데이터 메시와 도메인 주도 설계를 엮기
      • 유비쿼터스 언어와 결과 도메인 지식은 분석 모델 설계를 위한 필수 요ㅗ소
      • 자신의 실시간 데이터 모델과 다른 모델로 바운디드 컨텍스트 데이터를 노출하는 것은 오픈 호스트 패턴
      • 데이터 메시 아키텍처는 분석 유스케이스를 구현하기 위해 다양한 바운디드 컨텍스트의 모델을 묶기 때문에 실시간 데이터 모델을 위한 바운디드 컨텍스트의 연동 패턴은 분석 모델에도 적용됨
• 데이터 메시 아키텍처는 전통적인 데이터 관리 아키텍처의 어려움을 해결하는 데 목적이 있음. 분석 모델을 관리 가능한 단위로 분해하고 자체의 퍼블릭 인터페이스를 통해 분석 데이터에 안정적으로 접근하고 사용하도록 보장한다는 것. CQRS와 바운디드 컨텍스트 연동 패턴은 데이터 메시 아키텍처의 구현을 지원함