마디니블로그

CQRS 여러 애그리거트의 데이터가 필요한 조회 기능을 개발 할 때 조회 속도 개선과 함께 구현 방법에 대한 고민이 많아진다. 식별자 참조, 직접참조 등.. 객체 지향으로 도메인 모델을 구현할 때 주로 사용하는 (JPA와 같은)ORM 기법은 도메인 상태 변경 기능을 구현하는 데는 적합하지만 여러 애그리거트에서 데이터를 가져올 때는 고려할 게 많아 구현을 복잡하게 한다. 도메인 모델 관점에서 상태 변경 기능은 주로 한 애그리거트의 상태를 변경한다. 조회 기능은 애그리거트가 두 개 이상 필요할 때가 많다. 단일 모델로 두 기능을 구현 하면 불필요하게 복잡해진다. CQRS 는 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다. 각 모델에 맞는 구현 기술을 선택할 수 있다..

이벤트의 용도와 장점 구매를 취소할 때 다음과 같이 주문 도메인 클래스에서 주문 상태를 변경하고, 환불 서비스를 주입받아 환불 처리를 한다. (결제 시스템은 외부에 존재하므로 환불 서비스는 외부 결제 시스템이 제공하는 환불 서비스를 호출한다.) public class Order { // 외부 서비스를 실행하기 위해 도메인 서비스를 파라미터로 전달 받음 public void cancel(RefundService refundService) { // 주문 로직 verifyNotYetShipped(); this.state = OrderState.CANCELED; this.refundStatus = State.REFUND_STARTED; // 결제 로직 try { refundService.refund(getPay..

바운디드 컨텍스트 도메인 모델을 표현할 때 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있다. 한 개의 모델로 모든 하위 도메인을 표현하기 어렵다. 하위 도메인마다 모델을 만들어야 한다. 각 모델은 명시적으로 구분지어 섞이지 않도록 한다. [바운디드컨텍스트(BoundedContext)란] 모델은 특정한 컨텍스트 아래서 완전한 의미를 갖는데, 이때 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트(Bounded Context)라고 한다. 사용자에게 기능을 제공하는 물리적 시스템 모델의 경계를 결정, 한개의 바운디드 컨텍스트는 한개의 논리적으로 모델을 갖는다. 용어를 기준으로 구분한다. 팀 조직의 규모에 따라 하위 도메인별로 각 바운디드 컨텍스트를 가질 수도 있고, ..

애그리거트의 트랜잭션 운영자와 고객이 동시에 한 주문 애그리거트를 수정하는 경우 문제점 살펴보자. 아래 두 쓰레드는 각각 트랜잭션을 커밋할 때 수정한 내용을 DB에 반영한다. [문제점] 애그리 거트의 일관성이 깨질 수 있다. (운영자가 기존 배송지 정보를 이용해서 배송상태를 변경했는데 그 사이에 고객이 배송지를 변경 할 수 있다.) [해결] 운영자가 정보를 조회하고 변경하는 동안 고객이 애그리거트를 수정하지 못하도록 막는다 운영자가 정보를 조회한 후 고객이 정보를 변경하면, 운영자가 애그리거트를 다시 조회한 뒤 수정하도록 한다. -> DBMS가 지원하는 트랜잭션과 함께 애그리거트를 위한 추가적인 트랜잭션 처리 기법(선점 잠금/비선점 잠금)이 필요하다. 애그리거트 잠금기법 선점 잠금(Pessimistic ..

응용 서비스 응용 서비스 역할 표현 영역과 도메인 영역을 연결하는 매개체 사용자가 요청한 기능을 실행한다. -> 이 처리를 위해 리포지터리에서 도메인 객체를 가져와 사용한다. 도메인 같의 객체 흐름을 담당하기 때문에 다음과 같이 단순한 형태를 갖는다. //1. 리포지터리에서 애그리거트를 구한다. //2. 애그리거트의 도메인 기능을 실행 //3. 결과를 리턴 트랜잭션 처리도 담당하여 데이터 일관성이 깨지지 않도록 한다. -> 스프링 프레임워크가 제공하는 @Transactional로 쉽게 처리 가능 "응용 서비스가 복잡하다는 생각이 든다면?" 도메인 기능을 구현하고 있는지 체크 해볼 것 다음과 같이 비밀번호 변경 기능을 담당하는 ChangePasswordService 클래스가 있다. /* 서비스에 도메인(암..

스펙(Specification) CQRS 명령(Command)모델과 조회(Query)모델을 분리하는 패턴이다. 명령모델은 상태를 변경 하는 기능을 구현할 때 사용하며 주로 도메인 모델이 이에 해된다. 조회모델은 상태를 조회 하는 기능을 구현 할 때 사용 한다. 검새조건이 단순하고 고정되어 있는경우 JPA 메소드 사용 findByEmailAddressAndLastname findAllByDescriptionContaining 검색 조건을 다양하게 조합할 때 스펙을(specification) 사용한다. /** 특정조건을 충족하는지 검사할 때 사용하는 인터페이스 */ public interface Specification { public boolean isSatisfiedby(T agg); } [주문이 특정 ..

JPA를 이용한 리포지터리 구현 레포지토리 인터페이스는 도메인 영역에, 레포지토리 구현 클래스는 인프라스트럭처 영역에 속한다. 레포지토리는 기본적으로 ID로 애그리거트 조회 하기 와 애그리거트 저장하기 두개의 기능을 제공한다. 그외에도 다음과 가능 기능을 제공할 수 있다. ID외에 다른 조건으로 조회 JPA의 Criteria나 JPQL(Java Persistence Query Language) 사용 애그리거트 삭제 애그리거트 객체를 파라미터로 받음: delete(Order order); 요구사항이 삭제이더라도, 데이터를 바로 삭제하기보다는 삭제 플래그로 처리하여 일정기간 보관하는 것도 좋음 [SpringDataJPA 구현] 스프링 데이터 JPA는 다음 규칙에 따라 작성한 인터페이스를 찾고, 그 인터페이스..

애그리거트 서비스가 커지고 도메인이 복잡해지게 되면 => 개별 구성요소 위주로 도메인을 바라보게 된다. => 전체 구조나 상위 수준에서의 관계 파악이 어려워진다. => 상위수준에서 모델이 어떻게 엮여 있는지 몰라 코드 수정을 꺼려하게 된다. => 코드변경을 회피하는 쪽으로 요구사항을 협의하게 된다. => 코드 변경이나 확장이 어려워 진다. "애그리거트" 로 위와 같은 문제를 해결 할 수 있다. 애그리거트는 관련된 객체를 하나의 군으로 묶어 준다. 많은 객체들을 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 관계들을 파악하기 쉽다. [애그리거트 적용 전 도메인 모델] [애그리거트 적용 후 도메인 모델] 애그리거트의 특징 복잡한 도메인을 단순한 구조로 만들어 준다. -> 모델을 보다 잘 이해할 수 ..

아키텍처 표현 영역 사용자의 요청을 받아 응용 영역에 전달하고 응용영역의 결과를 다시 사용자에게 전달한다. HTTP요청을 응용 영역이 필요로 하는 형식으로 변환해서 응용 영역에 전달하고 응용영역의 응답을 HTTP응답으로 변환하여 전송한다. Controller 응용 영역 시스템이 사용자에게 제공해야할 기능을 구현 기능 구현을 위해 도메인 모델을 사용하고 로직을 직접 수행하기 보다는 도메인 모델에 로직 수행을 위임한다. Service 도메인 영역 도메인의 핵심로직을 구현 기능 구현을 위해 도메인 모델을 사용하고 고직을 직접 수행하기 보다는 도메인 모델에 로직 수행을 위임한다. @Entity, @Repository 인프라스트럭처 영역 논리적인 영역보다는 실제 구현을 다루는 영역 RDBMS, MONGO DB, ..

도메인이란? 도메인이란 소프트웨어의 구현을 통해 해결하고자 하는 문제나 주제를 말한다. 온라인 서점을 이용할 때 우리는 책을 검색하고, 장바구니에 담거나 쿠폰이 있는지 찾아보거나 구매를 한다. 구매를 할 때에는 다양한 페이나 포인트를 결제에 사용한다. 결제 이후에는 배송 추적이나 주문 상세 내역을 확인한다. 이때 '온라인 서점'이 하나의 도메인이 될 수 있다. 한 도메인은 하위 도메인으로 나눌 수 있는데, 예를 들어 온라인 서점의 하위 도메인으로는 주문 : 고객이 구매하는 과정을 처리 혜택: 할인이나 포인트 사용 등 ... 하위 도메인을 어떻게 구성할 지는 상황에 따라 다를 수 있다. 특정 도메인을 위한 소프트 웨어라고 해서 도메인의 모든 기능을 구현할 필요는 없다. 배송이나 결제는 외부 시스템을 사용하..