처음 DDD를 시작하는 사람들을 위한 가이드를 오해를 바로 잡기 위한 서적
- 비즈니스 도메인
- 기업의 주요 활동 영역
- 하위 도메인: 고객에게 제공하는 서비스 단위. 전체 시스템에서 하나의 구성요소
- 복잡성, 경쟁 우위에 따라 구분해야 한다
- 핵심 하위 도메인: 회사가 경쟁업체와 다르게 제공하는 활동(유즈케이스) → 복잡하고 어려운 도메인
- 일반 하위 도메인: 모든 회사가 같은 방식으로 수행하는 활동(유즈케이스) → 복잡할 수 있으나 변동성이 낮다
- 지원 하위 도메인: 회사의 비즈니스를 지원하는 활동(유즈케이스) → 복잡하지 않아 새로운 인재 양성의 좋은 기회
- 도메인 전문가: 비즈니스를 대표. 비즈니스 문제를 처음으로 파악한 사람
- 유비쿼터스 언어
- 도메인 전문가와 동일한 용어를 쓰는 것이 커뮤니케이션과 개발에 중요하다
- 기술 용어를 제외한 비즈니스 용어만으로 구성
- 도메인 모델: 사물이나 현상에서 의도한 관점만 강조하고 다른 측면을 무시하여 간략히 표현한 것 → 의도적 추상화
- 바운디드 컨텍스트
- 개별 유비쿼터스 언어를 사용하는 경계
- 하위 도메인은 비즈니스(논리적)에 의해 결정되나, 바운디드 컨텍스트(물리적)는 엔지니어에 의해 설계된다
- 하위 도메인과 1:1로 정렬되지 않는다
- 하나의 바운디드 컨텍스트는 반드시 한 팀만 소유해야 한다
- 하나의 바운디드 컨텍스트에 단일 아키텍처를 강요하면 안된다!
- 컨트랙트
- 바운디드 컨텍스트 간의 접점
- 협력형 패턴: 소통이 잘 되는 팀 패턴
- 파트너십: 각 바운디드 컨텍스트 간 연동의 조정이 양방향으로 이루어짐(AD-HOC)
- 공유 커널: 연동 관련 자료구조를 공통 모델로 정의하여 이루어짐
- 동일 팀 내에서 유용하며 자주 변하는 도메인이어야 한다
- 사용자-제공자 패턴: 연동의 불균형이 존재하는 팀 패턴
- 순응주의자: 서비스를 제공하는 업스트림에 의해 연동이 주도됨
- 충돌 방지 계층: 다운스트림이 업스트림에 제공하는 모델을 필요에 맞게 가공하여 사용함
- 오픈 호스트: 업스트림이 공표된(퍼블릭) 프로토콜을 제공하여 내부 모델 변경에 관계 없이 다운스트림이 사용 할 수 있도록 함
- 분리형 패턴: 커뮤니케이션/모델 차이로 인해 서로 협업하지 않는 패턴
- 비즈니스 로직 구현
- 트랜잭션 스크립트 패턴
- 프로시져를 기반으로 비즈니스 로직을 절차지향 스크립트로 구현
- 작업은 성공하거나 실패할 수 있지만 유효하지 않은 상태를 만들지 않는다
- 비즈니스 로직이 단순한 지원 하위 도메인에 적합하다
- 액티브 래코드 패턴
- 데이터 베이스 테이블 또는 행을 추상화, 캡슐화 하고 도메인 로직을 추가한 오브젝트
- 메모리 상의 객체를 데이터베이스 스키마에 맵핑하는 복잡성을 숨기는 것이 목적
- 지원/일반 하위 도메인, 외부 솔루션 연동, 모델 변환 작업에 적합
- 도메인 모델 패턴
- 복잡한 비즈니스 로직을 다루기 위한 패턴
- 핵심 하위 도메인에 이용된다
- 구성
- 밸류 오브젝트
- 복합적인 값에 의해 식별되는 객체
- 불변 객체로 구현된다
- 주로 엔티티의 속성으로 사용된다
- 엔티티
- 다른 엔티티와 구별하기 위해 명시적인 식별 필드(id)를 가진 객체
- 속성이 변할 것으로 예상되는 객체
- 어그리게이트
- 데이터의 일관성을 보호하기 위한 엔티티 집합 ( 1 ~ more )
- 다중 어그리게이트 트랜잭션이 존재해서는 안된다
- 강력한 일관성을 가진 엔티티만 가지며 나머지 로직의 연관 엔티티는 최종 일관성만을 지닌다
- 도메인 이벤트
- 비즈니스 도메인에서 일어나는 중요한 이벤트를 설명하는 메시지
- 과거형으로 명명
- 도메인 서비스
- 복수의 어그리게이트에 관련된 비즈니스 로직을 다루는 서비스
- 상태가 없는 객체로 주로 계산이나 분석을 담당
- 주로 여러 어그리게이트를 읽어 계산하는 로직을 담당하는 것이 좋다
- 시간 차원의 모델링 ( 이벤트 소싱 )
- 도메인 모델 패턴을 이용하나 어그리게이트의 상태를 저장하는 방식이 다른 구현
- 데이터 모델에 시간을 도입하여 모든 변경사항을 문서화하는 이벤트를 저장한다
- 시스템 데이터에 심오한 통찰력이 필요한 경우 적합
- 이벤트스토어: 이벤트를 저장하는 데이터베이스를 지칭
- 장점
- 해당 시간의 모델 상태를 재구성을 할 수 있다
- 감사 로그 또는 비즈니스에 이용할 수 있다
- 단점
- 학습 곡선이 높고, 모델의 진화가 매우 어렵다
- 단순 조회에는 매우 나쁜 성능을 보인다 → 스냅샷, 캐시, CQRS를 이용하여 개선 가능
- 아키텍처
- 계층형 패턴
- 톱-다운 커뮤니케이션으로 아래 레이어에만 항상 의존한다
- 트랜잭션 스크립트, 액티브 레코드와 잘 어울린다
- 계층의 종류
- 프레젠테이션 레이어: 상호작용을 위한 퍼블릭 인터페이스 레이어
- 서비스 레이어: 가용한 오퍼레이션을 구축하고 응답을 조정하는 레이어
- 비즈니스 로직 레이어: 비즈니스 로직을 구현하고 묶는 것을 담당
- 데이터 접근 레이어
- 영속성 저장소와 접근하는 것을 담당하는 레이어
- 다양한 외부 정보 제공자와 연동하는 것을 포함
- 포트와 어댑터(헥사고널)
- CQRS(command query responsibility segregation)
- 커뮤니케이션 패턴
- 휴리스틱 설계
- 이벤트 스토밍
- 마이크로 서비스
- 이벤트 기반 서비스
- 데이터 메시
- 커뮤니케이션은 프로젝트가 실패하는 가장 주요한 원인 중 하나
- 원시 집착 코드 징후: 원시 데이터 타입에 전적으로 의존해서 비즈니스 도메인 개념을 표현하는 것