늘로그

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. 단일 모델의 단점 주문 내역 조회 기능을 구현하려면 여러 애그리거트에서 데이터를 가져와야 한다. 조회 속도가 빠를수록 좋다면, 여러 애그리거트에서 데이터를 가져와야 할 경우 구현 방법을 고민해봐야 한다. ID를 이용해서 애그리거트를 참조하는 방식을 사용하면 즉시 로딩 방식을 사용할 수 없어 여러 select 쿼리를 보내야 한다. 직접 참조하는 방식으로 연결해도, 조회 화면의 특성에 따라 같은 연관도 즉시, 지연으로 처리해야 하기 때문에 고민이 생긴다. (경우에 따라 네이티브 쿼리를 날려야 할지도 모름!) 이러한 고민이 발생하는 이유는 시스템의 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기..

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. 시스템 간 강결합의 문제 쇼핑몰에서 구매를 취소하면 환불을 처리해야 한다. 이때 환불 기능을 실행하는 주체는 주문 도메인 엔티티가 될 수 있다. 도메인 객체에게 환불 기능을 실행하려면 다음 코드처럼 구현할 수 있다. public class Order { ... //외부 서비스를 실행하기 위해 도메인 서비스를 파라미터로 받음 public void cancel(RefundService refundService) { verifyNotYetShipped(); this.state = OrderState.CANCELED; this.refundStatus = State.REFUND_STARTED; try { re..

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. 도메인 모델과 경계 한 개의 모델로 여러 하위 도메인을 모두 표현하려고 시도하게 되면 모든 하위 도메인에 맞지 않는 모델을 만들게 된다. 주문에서의 상품, 배송에서의 상품, 재고 관리에서의 상품은 이름만 같지 실제로 의미하는 것은 다르다. 아래와 같이 논리적으로 같은 존재처럼 보이지만 하위 도메인에 따라 다른 용어를 사용하는 경우도 있다. 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있기 때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수도 없다. 하위 도메인마다 사용하는 언어가 다르기 때문에 올바른 도메인 모델을 개발..

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. 애그리거트와 트랜잭션 (거의 동시에)한 주문 애그리거트에 대해 운영자는 배송 준비 상태로 변경할 때, 사용자는 배송지 주소를 변경하는 경우에 애그리거트의 일관성이 깨질 수 있다. 운영자 스레드와 고객 스레드는 같은 주문 애그리거트를 나타내는 다른 객체를 구하게 되는데, 주문 애그리거트 객체를 배송 상태로 변경하더라도 고객 스레드에서 사용하는 주문 애그리거트 객체에는 영향을 주지 않는다. 이러한 문제가 발생하지 않도록 하려면 다음의 두 가지 중 하나를 해야 한다. 운영자가 배송지 정보를 조회하고 상태를 변경하는 동안 고객에 애그리거트를 수정하지 못하게 막는다. 운영자가 배송지 정보를 조회한 이후에 고객..

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. 여러 애그리거트가 필요한 기능 한 애그리거트로 기능을 구현할 수 없을 때가 있다. 예로는 결제 금액 계산 로직이 있는데, 실제 결제 금액을 계산할 때는 다음 내용이 필요하다. 상품 애그리거트 : 구매하는 상품의 가격이 필요하며 상품에 따라 배송비가 추가되기도 함 주문 애그리거트 : 상품별로 구매 개수 필요 할인 쿠폰 애그리거트 : 쿠폰별로 지정한 할인 금액, 비율에 따라 주문 총금액을 할인 회원 애그리거트 : 회원 등급에 따라 추가 할인이 가능 총 주문 금액은 주문 애그리거트가 담당할 수 있지만, 실제 결제 금액은 이야기가 다르다. 할인 쿠폰 애그리거트가 담당하기에는 할인 쿠폰을 두 개 이상 적용할 ..

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. 표현 영역과 응용 영역 도메인이 제 기능을 하려면 사용자와 도메인을 연결해 주는 매개체가 필요하다. 응용 영역과 표현 영역은 사용자와 도메인을 연결해 주는 매개체 역할을 한다. 표현 영역 사용자의 요청을 해석하고, 응용 서비스에 맞게 변환 표현 영역은 URL, 요청 파라미터, 쿠키, 헤더 등을 이용해 사용자가 어떤 기능을 실행하고 싶어 하는지 판별하고 기능을 제공하는 응용 서비스를 실행 응용 서비스를 실행한 뒤 표현 영역은 실행 결과를 사용자에 알맞은 형식으로 응답(HTML, JSON, XML...) 응용 영역 실제 사용자가 원하는 기능을 제공하는 것은 응용 영역에 위치한 서비스 실제로 사용자의 요청..

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. 검색을 위한 스펙 애그리거트를 찾을 때 식별자를 이용하는 것이 기본이지만 식별자 외에 여러 다양한 조건으로 애그리거트를 찾아야 하는 경우가 있다. 검색 조건이 다양해지면 모든 조합별로 `find 메서드(파라미터)` 형식으로 정의하기 어렵다. 이러한 경우 스펙(Specification)을 이용해서 해결 가능하다. 스펙은 애그리거트가 특정 조건을 충족하는지 여부를 검사한다. public interface Specification { public boolean isSatisfiedBy(T agg); } isSatisfiedBy() : 검사 대상 객체가 조건을 충족하면 true를 리턴한다. agg 파라미터 ..

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. JPA를 이용한 리포지터리 구현 애그리거트를 어떤 저장소에 저장하느냐에 따라 리포지터리를 구현하는 방법은 다르다. 데이터 보관소로 RDBMS를 사용할 때 객체 기반의 도메인 모델과 관계형 데이터 모델 간의 매핑을 처리하는 기술로 ORM만한 것이 없다. 모듈 위치 리포지터리 인터페이스는 애그리거트와 같이 도메인 영역에 속한다. 그리고 리포지터리를 구현한 클래스는 인프라스트럭처 영역에 속한다. 팀 표준에 따라 domain.impl과 같은 패키지에 위치 하는 경우도 있다. 이는 인터페이스와 구현체를 분리하기 위한 타협안이지 좋은 설계 원칙을 따르는 것이 아니다. 가능하면 인프라스트럭처 영역에 위치시키자. ..

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. 애그리거트 (상위 모델에 대한 이해 없이) 개별 객체 수준에서 모델을 바라보는 것보다 상위 수준에서 모델을 정리하면 복잡한 도메인 모델의 관계를 이해하는 데 도움이 된다. 애그리거트는 관련된 객체를 하나의 군으로 묶어준다. 그리고 애그리거트로 묶어서 바라보면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있다. 즉, 애그리거트는 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들어 준다. 애그리거트는 일관성을 관리하는 기준이 된다. 애그리거트를 단위로 일관성을 관리하기 때문에 애그리거트는 복잡한 도메인을 단순한 구조로 만든다. 애그리거트는 관련된 모델을 하나로 모은 것이기 때문에 한 애그리..

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. 네 개의 영역 아키텍처를 설계할 때 전형적으로 '표현', '응용', '도메인', '인프라스트럭처' 네 가지 영역이 출현한다. 표현 영역 또는 UI 영역은 사용자의 요청을 받아 응용 영역에 전달, 응용 영역의 결과를 다시 사용자에게 보여주는 역할을 한다. 이때 사용자는 외부 시스템(REST 방식이라면)이나 브라우저 사용자일 수 있다. 스프링 MVC 프레임워크는 표현 영역을 위한 기술 중 하나이다. 응용 영역은 표현 영역을 통해 사용자의 요청을 전달받고 시스템이 사용자에게 제공해야 할 기능을 구현한다. 응용 영역은 로직을 직접 수행하지 않고, 도메인 모델에 로직 수행을 위임한다. 도메인 영역은 도메인 모..

최범균님의 DDD START!를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다. 1. 도메인 도메인이란 소프트웨어로 해결하고자 하는 문제 영역으로 예컨대 온라인 서점이 있다. 한 도메인은 다시 하위 도메인으로 나눌 수 있다. 도메인은 하위 도메인으로 구성된다. (회원, 혜택, 주문, 정산...) 한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공 특정 도메인을 위한 소프트웨어라고 해서 도메인이 제공해야 할 모든 기능을 구현하는 것이 아니다. 도메인마다 고정된 하위 도메인이 존재하지 않는다. ex) 혜택 제공 없을 수도 있음 하위 도메인을 어떻게 구성할지 여부는 상황에 따라 달라짐 2. 도메인 모델 도메인 모델이란 특정 도메인을 개념적으로 표현한 것이다. 객체 모델이나 U..