좋은 코드 56

DDD START! - CQRS

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

DDD START! - 이벤트

최범균님의 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! - 도메인 모델과 BOUNDED CONTEXT

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

DDD START! - 애그리거트 트랜잭션 관리

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