주난v 개발 성장기

CQRS - Command Query Responsibility Segregation 단일 모델의 단점 조회 화면의 특성상 속도가 빨라야 하는데, 여러 애그리거트에서 데이터를 가져와야 할 경우 구현 방법을 고민해야 한다. (ex. 주문 상세 조회 시에 주문, 상품, 회원 정보를 모두 조회해한다.) ID를 이용해서, 애그리거트를 참조하는 방식을 사용하면 즉시 로딩과 같은 최적화 기능을 이용 못하고, 여러번 select를 해야함으로 속도에 문제가 생긴다. ID가 아니라 직접 참조하는 방식으로 연결해도 즉시 로딩이나 지연 로딩을 처리해야 하므로, 네이티브 쿼리를 사용해야 할 수도 있다. 이러한 고민은 단일 도메인을 사용하기 때문이다. 해결법은 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것! CQRS..

애그리거트와 트랜잭션 운영자 스레드와 고객 스레드는 개념적으로 동일한 애그리거트지만, 물리적으로는 다른 애그릭더트 객체 이다. 운영자 스레드가 주문 애그리거트 객체의 배송 상태를 변경했는데, 고객이 그 사이에 배송지 정보를 변경 --> 애그리거트의 일관성이 깨진다. 이를 보완하는 트랜잭션 처리 기법이 필요! 1. 선점(Pessimistic) 잠금 - 먼저 애그리거트를 구한 스레드가 사용이 끝날 때까지 다른 스레드가 해당 애그리거트를 수정하는 것을 막는다. 한 스레드가 애그리거트를 구하고 수정하는 동안 다른 스레드가 수정할 수 없으므로, 동시에 데이터를 수정하는 충돌 문제 해결 가능 선점 잠금 방식은 DBMS가 제공하는 행 단위 잠금을 사용해서 구현한다. LockModeType.PESIMISTIC_WRIT..

여러 애그리거트가 필요한 기능 한 애그리거트로 기능을 구현할 수 없을 때가 있다. (ex. 결제 금액 계산 로직...상품 / 주문 / 할인 쿠폰 / 회원 애그리거트를 모두 필요로 함) 주문 금액을 계싼하는 것은 주문 애그리거트에서 할 수 있지만, 실제 결제 금액은 누구의 책임일까..? 주문 애그리거트가 필요 데이터를 모두 가지고, 주문 애그리거트에서 처리..? 계산 로직이 주문 애그리거트에 있는 문제 할인 건이 생겨도, 주문 쪽 코드를 수정해야 함 --> 애그리거트는 자신의 책임 범위를 넘어서는 기능을 구현, 의존성이 증가 도메인 서비스 한 애그리거트에 억지로 넣기보다 도메인 서비스를 이용해서 도메인 개념을 명시적으로 드러내면 된다. public class DiscountCalculationService..

도메인 영역만 잘 만든다고, 사용자의 요구를 충족한다고 끝나는 것은 아니다. 도메인이 제 기능을 하려면 사용자와 도메인을 연결해 주는 매개체가 필요하다. (표현 - 응용 - 도메인) 표현 영역 - 사용자의 요청 해석 (어떤 기능을 실행하고 싶어하는지...), 응용 서비스 실행 - 응용 서비스에서 원하는 형태로 사용자의 요청을 변환 응용 영역 - 기능 제공 - repository로 부터 도메인 객체를 구하고, 사용 - 유효성 검사, 애그리거트 CRUD, 결과 리턴 이외의 것이 들어있으면 도메인 로직의 일부를 구현하고 있을 가능성이 있다. - 트랜잭션 처리 도메인 로직 넣지 않기 public class ChangePasswordService { public void changePassword(String m..

애그리거트는 관련된 객체를 하나의 군으로 묶어준다. 애그리거트를 이용하여 모델 간의 관계를 개별 수준뿐만 아니라 상위 수준에서도 이해가능하다. 일관성을 관리하는 기준이 되기도 한다. 애그리거트 관련된 모델을 하나로 모은 것 동일한 라이프 사이클 Order가 생성되면, OrderLine, ShippingInfo등 애그리거트에 속한 구성 요소는 대부분 함께 생성하고 소멸된다. 애그리거트는 경계를 가진다. 경계의 설정은 도메인 규칙, 요구사항이 중요하다. 하지만, 'A가 B를 갖는다'고 가정한다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다. 그러나 그렇지 않다. Product - Review같은 경우는 함께 생성되거나 변경되지 않고, 변경주체도 다르다. 애그리거트 루트 구매할 상품의 개수를 변경하면, O..

네 개의 영역 표현 영역 사용자의 요청을 받아 응용 영역에 전달 응용 영역의 처리 결과를 다시 사용자에게 전달 도메인 영역 도메인 모델 구현 Order, OrderLine 등이 도메인 모델 영역에 위치한다. Entity, Value Object 인프라스트럭처 영역 구현 기술 RDB, SMTP, Queue 계층 구조 아키텍쳐 도메인의 복잡도에 따라 응용과 도메인을 분리하기도 하고, 합치기도 한다. 계층 구조는 상위 계층에서 하위 계층으로만 의존하고, 역으로는 발생하지 않는다. 응용 영역과 도메인 영역은 DB나 외부 시스템 연동을 위해 의존하나, 응용에서 도메인을 무조건 의존 할 필요는 없다. 결국, 표현 - 응용 - 도메인 계층은 모두 인프라스트럭처에 의존하게 되고, 별도의 외부 기술(가격 할인 등)과 같..

도메인 "서점" 도메인 회원, 주문, 결제, 배송 하위 도메인 존재 도메인 모델 패턴 사용자 인터페이스, 표현 계층 사람, 외부 API 등 에게 요청을 받고, 정보를 보여줌 사용자의 세션을 관리 응용 계층 비즈니스 로직 X 각 도메인 계층에 업무를 위임하고, 이를 조합하여 실행 도메인 계층 비즈니스 로직 인프라 스트럭쳐 계층 RDB SQS, MQTT API Q ) 새로운 요구사항 출고 전에 배송지를 변경 할 수 있다. 주문 취소는 배송전에 할 수 있다. 이 2가지 요구사항을 각각 출고 서비스, 주문 서비스, 배송 서비스에서 구현을 해도 할 수는 있지만, 유지보수가 어렵고 한 쪽에서 정책이 바뀐다면 모든 코드를 다 확인해야 한다. public class Order { private OrderState st..