요약
- 5장. 마이크로서비스 설계 나머지 부분에 대해 이해함.
- 도메인 모델링
- DDD의 전술적 설계(도메인 모델링 구성요소)
- 엔티티
- 값 객체
- 표준 타입
- 애그리거트
- 도메인 서비스
- 도메인 이벤트
메모
5.6 도메인 모델링
- 도메인 모델링은 백엔드 모델링의 일부분이지만, 마이크로서비스를 설계하는 데 있어서 중요한 부분을 차지함.
- 마이크로서비스의 내부 구조는 '폴리글랏'하게 접근할 수 있음.
- '폴리글랏'은 애플리케이션을 구현하는 언어나 데이터를 저장하는 저장소를 서비스마다 다양하게 활용할 수 있다는 의미이며, 내부 아키텍처 구조를 서비스 특성에 맞게 다양하게 수립할 수 있다는 의미임.
- 내부 영역의 구조를 도메인 모델 중심으로 만들 수도 있고, 트랜잭션 스크립트 형태로 만들 수도 있음.
- 도메인 모델 중심의 구조에서는 도메인 모델을 중심으로 모델링을 수행하며, 비즈니스 로직이 도메인 모델로 위임되어 적절히 분산됨.
- 이와 반대로, 트랜잭션 스크립트의 구조에서는 DTO가 데이터 묶음의 역할만 수행하며, 서비스가 많은 로직을 보유하게 되어 시스템이 복잡해질수록 비대해질 수 있음.
- 단순한 로직인 경우에는 트랜잭션 스크립트 구조로 만들어도 괜찮지만, 비즈니스가 복잡해질수록 비즈니스 개념들을 잘 구조화할 수 있는 도메인 모델 구조가 효과적임.
- 왜냐하면 도메인 모델 구조는 복잡함을 다루어 쉽게 표현할 수 있는 구조를 제공하기 때문임.
- 마이크로서비스의 내부 영역을 도메인 모델 구조로 정의했을 때 설계하는 방식이 바로 도메인 모델링임.
- 도메인 모델링은 객체 모델링의 의미로 광범위하게 사용되지만, 여기서는 DDD의 전술적 설계를 활용해 객체 모델링을 진행하는 방식을 의미함.
5.6.1 DDD의 전술적 설계(도메인 모델링 구성요소)
- DDD(Domain-Driven Design)의 전술적 설계는 도메인 모델을 구성하기 위한 패턴들을 제공함.
- 기존 객체 모델링 방식은 자유도가 높아 문제 영역을 파고들수록 복잡한 계층 구조를 만들 가능성이 높음.
- 이런 복잡함을 해결하기 위해, DDD의 전술적 설계는 객체들의 역할에 따른 유형을 정의하고, 이 규칙에 따라 모델링을 진행함.
- 이런 접근 방식을 사용하면 모델링이 단순해지고 이해하기가 수월해짐.
- DDD의 전술적 설계에는 다양한 구성 요소가 있지만, 이 책에서는 도메인 모델을 구성하는 객체 구성 요소에 초점을 맞추어 설명하고 있음.
엔티티
- 엔티티는 도메인의 실체 개념을 표현하는 객체로, 다른 엔티티와 구별할 수 있는 고유 식별자를 가짐.
- 이 식별자는 고유하지만, 엔티티의 속성과 상태는 시간이 지나면서 변할 수 있음.
- 도메인에서 개별성(individuality)을 가지는 개념을 엔티티로 식별함.
- 엔티티와 값 객체의 주요 차이점은 바로 이 고유 식별자와 변화 가능성(mutability)임.
- 예를 들어, 구매라는 도메인 개념은 '구매번호'라는 고유 식별자로 구분할 수 있으며, 구매품이나 수취자 등이 개별적으로 변경될 수 있기 때문에, 이를 엔티티로 모델링할 수 있음.
값 객체
- 값 객체(Value Object)는 각 속성이 개별적으로 변하지 않는 개념적 완전성을 모델링함.
- 이는 전체 객체가 한 번에 생성되거나 삭제되며, 개별 속성이 별개로 수정되지 않는 객체임.
- 엔티티와 달리 값 객체는 고유 식별자에 의해 구별되지 않고, 속성의 값에 의해 동일함이 결정됨.
- 값 객체의 특성은 다음과 같이 정의됨
- 도메인 내의 어떤 대상을 측정하고, 수량화하고, 설명함.
- 관련 특징을 모은 필수 단위로 개념적 전체를 모델링함.
- 측정이나 설명이 변경될 땐 완벽히 대체 가능함.
- 다른 값과 등가성을 사용해 비교할 수 있음.
- 값 객체는 일단 생성되면 변경할 수 없음.
- 예를 들어, '구매자', '수취자', '구매품' 등은 구매를 구성하는 속성을 표현하는 개념으로, 이들을 값 객체로 모델링할 수 있음.
- 구매품의 개별 속성들은 별도로 변경되지 않으며, 구매품 전체가 추가되거나 삭제만 가능함.
표준 타입
- 표준 타입은 대상의 타입을 나타내는 서술적 객체로, 엔티티나 값 객체의 속성을 구분하는 용도로 사용됨.
- 이를 통해 동일한 값 객체나 엔티티라도 다른 의미나 역할을 가질 수 있음을 명시적으로 표현할 수 있음.
- 예를 들어, '전화번호'라는 값 객체가 있을 때, 이 전화번호가 '집 전화', '핸드폰 전화', 또는 '회사 전화번호'인지 구분하기 위해 표준 타입을 사용gka.
- 과거에는 이러한 구분을 코드 값으로 모델링하곤 했지만, 이 방식은 매핑표가 필요하고 가독성이 떨어져 이해하기 어려움.
- 따라서 컨텍스트에 맞는 이해 가능한 유비쿼터스 용어로 정의하는 것이 바람직함.
- 예를 들어, 자바 언어에서는 보통 열거형(Enumeration)으로 정의함.
- '멤버십 등급 유형'이라는 표준 타입은 이런 예시로, 열거형으로 'VIP', 'GOLD', 'SILVER'로 구분해서 표현됨.
애그리거트
- 애그리거트는 관련된 엔티티, 값 객체, 표준 타입들의 묶음이며, 이들 간에는 비즈니스 의존관계가 존재함.
- 이 구조는 비즈니스 로직의 일관성을 보장하고, 트랜잭션의 기본 단위가 됨.
- 애그리거트 내에서는 가장 상위 엔티티를 애그리거트 루트로 정하며, 이 루트를 통해서만 애그리거트 내의 다른 엔티티나 값 객체를 변경할 수 있음.
- 일반적으로 하나의 컨텍스트에는 하나의 애그리거트가 식별되지만, 여러 애그리거트가 존재할 수도 있음.
- 이 경우, 다른 애그리거트를 참조할 때는 직접 참조하지 않고 참조할 애그리거트 루트의 식별자를 통해 간접적으로 참조하는 것이 바람직함.
- 이는 애그리거트 단위의 트랜잭션 처리를 용이하게 하고, 의존관계의 복잡성을 줄임.
- 또한, 애그리거트는 마이크로서비스의 후보가 될 수 있으므로, 간접 참조는 서비스 분리를 용이하게 함.
- 다른 애그리거트 사이의 일관성이 필요할 경우에는 도메인 이벤트를 활용하여 결과적 일관성을 유지함.
- 즉, 한 애그리거트의 변경이 다른 애그리거트에 영향을 미치는 경우, 도메인 이벤트를 통해 갱신하고 일관성을 유지함.
도메인 서비스
- 도메인 서비스는 도메인의 비즈니스 로직 처리가 특정 엔티티나 값 객체에 속하지 않을 때 사용하는 독립적인 객체임.
- 이 서비스는 상태를 관리하지 않고, 행위만을 관리함.
- 즉, 도메인 서비스는 특정 작업을 처리하며 그 상태를 본인이 가지고 있지 않음.
- 대신, 이 상태는 관련 엔티티나 값 객체에 전달됨.
- 이렇게 함으로써, 도메인 서비스는 비즈니스 로직을 캡슐화하고, 이 로직이 적절한 엔티티나 값 객체로 이동될 수 있도록 함.
도메인 이벤트
- 도메인 이벤트는 서비스 간의 정합성을 유지하기 위해 사용되는 구현 객체임.
- 이것은 주요 상태 값을 포함하며, 이 정보는 서비스 간에 전달되어야 함.
- 예를 들어, '주문' 엔티티와 '주문아이템' 엔티티가 생성되어 저장될 때, 주문 처리를 수행하는 트랜잭션과 동시에 '구매완료됨'이라는 도메인 이벤트가 발행됨.
- 이 '구매완료됨' 이벤트는 주문 상태를 나타내는 주요 정보를 포함함.
- 이 이벤트는 메시지 메커니즘을 통해 다른 서비스에 전달되고, 이를 통해 예를 들어 배송 서비스는 배송 처리를 수행할 수 있음.
- 이렇게 도메인 이벤트는 각 서비스의 상태 변화를 전달하고, 다른 서비스가 이를 반영하여 전체 시스템의 일관성을 유지하는 역할을 함.
댓글