본문 바로가기

DDD 도메인주도설계

도메인주도개발 시작하기 11장 CQRS CQRS란 Command and Query Responsibility Segregation 의 약자로, 데이터 저장소로부터의 읽기와 업데이트 작업을 분리하는 패턴을 말한다 여러 애그리거트의 데이터가 필요하면 다양한 방안의 구현방법을 고민해야한다. 식별자를 이용해서 애그리거트를 참조하는 방식을 사용하여 가져와한다. 상태 변경 기능은 주로 한 애그리거트의 상태를 변경한다. 반면, 조회 기능은 두 개 이상의 애그리거트가 필요할 때가 많다. 상태를 변경하는 범위와 조회하는 범위가 일치하지 않기 때문에 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다. 위 복잡도를 해결하기 위해 사용하는 방법이 CQRS이다. CQRS : 명령(Command)을 위한 모델과 조회(Query)를 위한 모델을 분리하.. 더보기
도메인주도개발 시작하기 10장 이벤트 ## 시스템 간 강결합 문제 쇼핑몰에서 구매를 취소하면 환불처리를 해야한다. 이때 보통 결제 시스템은 외부에 있으므로 Order 도메인에서 구매 취소에 관련된 서비스를 다음과 같이 파라미터로 주입할 것이다. 위처럼 외부 시스템을 도메인에서 호출 시 3가지 문제가 발생할 수 있다. 1. 외부 서비스가 비정상일 경우 트랜젝션 처리를 어떻게 할까? - 롤백을 해야할까? 일단 커밋을 해야할까?, 아니면 상태만 변경한 후에 나중에 다시 시도를 해야할까? 2. 외부 시스템의 응답 시간이 길어지면 어떻게 할까? - 대기 시간만큼 응답시간이 길어져서 성능에 악영향을 주지 않을까? 3. 도메인 객체에 서비스를 전달하면 설계상 문제가 발생하지 않을까? - 도메인 로직과 외부 로직이 뒤섞이지 않을까? 바운디드 컨텍스트 간 .. 더보기
도메인주도개발 시작하기 9장 바운디드컨텍스트 # 바운디드 컨텍스트 간 통합 - 인프라 영역에서 외부 시스템과의 연동을 처리 - RecSystemClient에서 도메인 모델 변환하는 작업을 처리 - 두 모델 간 변환 과정이 복잡하면 변환 처리를 위한 별도 클래스 생성 가능 - Rest API를 통해 두 바운디드 컨텍스트를 직접 통합할 수 있고, 메시지큐를 사용하여 간접적으로 통합할 수도 있음 - 비동기적으로 처리 가능 - 단, 두 바운디드 컨텍스트가 사용할 메시지의 데이터 구조를 맞춰야 - 변경 내용을 여러 컨텍스트에 pub-sub 가능 그럼 여기서 , microservice간 restapi 와 message queue로 처리하는 방식의 차이는 뭘까 REST API 통신: 장점: - 간단하고 직관적인 통신 방식으로, HTTP 프로토콜을 사용하여 통신.. 더보기
도메인주도개발 시작하기 8장 애그리거트 트랜잭션관리 8.1 애그리거트와 트랜잭션 한 주문 애그리거트에 대해 운영자는 배송 준비 상태로 변경할 때 사용자는 배송지 주소를 변경한다면 어떻게 될까 스레드는 각각 트랜잭션을 커밋할 때 수정한 내용을 DBMS에 반영함. 때문에 하나의 애그리거트를 여러 사용자가 동시에 변경하고자한다면 데이터의 일관성이 깨질 수 있음 이런 문제를 방지하기 위해서는 아래와 같은 방법을 사용해야 함 운영자가 배송지 정보를 조회하고 상태를 변경하는 동안 고객이 애그리거트를 수정하지 못하게 막는다. (Pessimistic) 운영자가 배송지 정보를 조회한 이후에 고객이 정보를 변경하면 운영자가 에그리거트를 다시 조회한 뒤 수정하도록 한다. (Optimistic) 낙관적락 : 충돌이 발생하지 않을거야 라고 낙관적으로 생각함 (비선점) -> 버전.. 더보기
도메인주도설계 7장 도메인 서비스는 도메인 로직을 수행하지 응용 로직을 수행하진 않는다. 트랜잭션 처리와 같은로직은 응용로직이므로 도메인 서비스가 아닌 응용서비스에서 처리해야 한다. 특정 기능이 응용서비스인지 도메인 서비스인지 감을 잡기 어려울 때는 해당 로직이 애그리거트의 상태를 변경하거나 애그리거트의 상태 값을 계산하는지 검사해봐야한다. 예를 들어 계좌 이체 로직은 계좌 어그리거트의 상태를 변경하고 결제금액 로직은 주문 애그리거트의 주문금액을 계산한다. 두 로직은 각각 애그리거트를 변경하고 애그리거트의 값을 계산하는 도메인로직이다. 도메인 로직이면서 한 애그리거트에 넣기에 적합하지않으므로 이 두 로직은 도메인 서비스로 구현하게된다. 즉, 두개의 어그리거트의 상태값을 변경하는 것은 하나의 도메인로직에 넣기가 적합하지않으.. 더보기
도메인주도설계 6장 # 표현 영역과 응용 영역 - 응용 영역과 표현 영역이 사용자와 도메인을 연결해주는 매개체 역할을 함 - 표현 영역은 응용 서비스가 요구하는 형식으로 사용자 요청을 변환. - 응용 서비스를 실행한 뒤에 표현 영역은 실행 결과를 사용자에게 알맞은 형식(HTML/JSON)으로 응답 # 응용 서비스의 역할 & 주의점 응용 서비스는 사용자가 요청한 기능을 실행하는 영역을 담당한다. 이 때 리포지터리로부터 도메인 객첼르 구하고, 도메인 객체를 사용한다. 주의 사항은 응용 서비스에서 도메인 로직을 넣어서는 안된다. 응용 서비스에서 도메인 로직을 넣으면 두 가지 단점이 존재한다. 코드의 응집도가 떨어진다. 응용 서비스에서 동일한 도메인 로직을 구현할 가능성이 높아진다. (이는 실제로 몇 번 경험한 이슈) 도메인 로직.. 더보기
도메인주도설계 5장 CQRS : 명령 모델과 조회 모델을 분리하는 패턴. 상테(데이터) 변경 기능 구현시에는 명령 모델, 데이터를 보여주는 기능을 구현할 때는 조회 모델 사용 # 검색을 위한 스펙 스팩 Specification : 검색 조건을 다양하게 조합해야 할 때 사용할 수 있는 것 agg는 애그리거트 루트, agg는 검색 결과로 리턴할 데이터 객체가 됨. Spec 인터페이스 예시 Spec 인터페이스 구현 예시 만약 리포지터리가 메모리에 모든 애그리거트를 보관하고 있다면 다음과 같이 사용 가능하나, 실제로는 모든 데이터를 메모리에 저장을 못하기에 사실상 위와 같이 사용 불가능 실제 스펙은 사용하는 기술에 맞춰 구현하게 됨 # 스프링 데이터 JPA를 이용한 스펙 구현 JPA 크리테리아 API를 같이 이용 스펙은 and 혹.. 더보기
도메인주도개발 시작하기 4장 JPA 를 이용한 리포지터리 구현 도메인 모델과 리포지터리를 구현할 때 선호하는 기술은 JPA 를 들 수 있다. 데이터 보관소로 RDMS 를 사용할 때 객체 기반의 도메인 모델과 관계형 데이터 모델 간의 매핑을 처리하는 기술로 ORM 만한 것이 없다. 모듈 위치 리포지터리 인터페이스는 애그리거트와 같이 도메인 영역에 속하고 리포지터리를 구현한 클래스는 인프라스트럭처 영역에 속한다. 이는 리포지터리 구현 클래스를 인프라스트럭처 영역에 위치시켜서 인프라스트럭처에 대한 의존을 낮춰야 한다. DIP에 따라 리포지터리 구현 클래스는 인프라스트럭처 영역에 위치한다. 즉 , mongodb,mysql,postgre등등 구현기술은 인프라스트럭처계층에서 구현하고 언제든지 바꿔낄 수 있어야한다. 리포지터리가 제공하는 기능은.. 더보기

티스토리툴바