## 시스템 간 강결합 문제 쇼핑몰에서 구매를 취소하면 환불처리를 해야한다. 보통 결제 시스템은 외부에 있으므로 Order 도메인에서 구매 취소에 관련된 서비스를 다음과 같이 파라미터로 주입할 것이다 위처럼 외부 시스템을 도메인에서 호출 시 3가지 문제가 발생할 수 있다. 1. 외부 서비스가 비정상일 경우 트랜젝션 처리를 어떻게 할까? - 롤백을 해야할까? 일단 커밋을 해야할까?, 아니면 상태만 변경한 후에 나중에 다시 시도를 해야할까? 2. 외부 시스템의 응답 시간이 길어지면 어떻게 할까? - 대기 시간만큼 응답시간이 길어져서 성능에 악영향을 주지 않을까? 3. 도메인 객체에 서비스를 전달하면 설계상 문제가 발생하지 않을까? - 도메인 로직과 외부 로직이 뒤섞이지 않을까? 위 문제가 발생하는 이유는 바..

# 도메인 모델과 경계 - 도메인 모델을 만들 때 처음부터 완벽하게 단일 모델을 만들 수는 없음. - 한 도메인은 다시 여러 하위 도메인으로 구분됨. - 한 도메인을 논리적으로 같아 보여도 하위 도메인에 따라 다른 용어를 사용할 수 있음 - 하위 도메인마다 같은 용어라도 의미가 다르기 때문에 한 개의 모델로 모든 하위 도메인을 표현할 수 없음 - 올바른 도메인 모델을 개발하려면 하위 도메인 마다 모델을 다르게 만들어줘야 - 각 모델은 명시적으로 구분되는 경계를 가져야 함. - 바운디드 컨텍스트 : 구분되는 경계를 갖는 컨텍스트 # 바운디드 컨텍스트 - 모델의 경계를 결정 - 하나의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 가짐 - 이상적으로는 하위 도메인과 바운디드 컨텍스트가 일대일이면 좋겠으나, ..

# 시작에 앞서 CQRS : 명령 모델과 조회 모델을 분리하는 패턴. 상테(데이터) 변경 기능 구현시에는 명령 모델, 데이터를 보여주는 기능을 구현할 때는 조회 모델 사용 # 검색을 위한 스펙 스팩 Specification : 검색 조건을 다양하게 조합해야 할 때 사용할 수 있는 것 agg는 애그리거트 루트, agg는 검색 결과로 리턴할 데이터 객체가 됨. 만약 리포지터리가 메모리에 모든 애그리거트를 보관하고 있다면 다음과 같이 사용 가능하나, 실제로는 모든 데이터를 메모리에 저장을 못하기에 사실상 위와 같이 사용 불가능 실제 스펙은 사용하는 기술에 맞춰 구현하게 됨 # 스프링 데이터 JPA를 이용한 스펙 구현 JPA 크리테리아 API를 같이 이용 스펙은 and 혹은 or, where 등으로 조합이 가능..

도메일 모델 시작하기 도메인에 따라 용어의 의미가 결정 여러 하위 도메인을 하나의 다이어그램에 모델링 하면 안 됨 각 하위 도메인마다 별도 모델을 만들어야 아키텍처 구성 표현 영역 : 사용자 요청 처리/사용자에게 정보 제공 HTTP 요청을 응용영역이 필요로 하는 형식으로 변환헤서 전달 응용 영역 : 사용자가 요청한 기능 실행 : 업무 로직을 직접 구현하지 않음 응용 서비스를 로직을 직접 수행하지 않고, 도메인 모델에 로직 수행을 위임 도메인 영역 : 시스템이 제공할 도메인 규칙 구현 도메인 핵심 로직 구현 인프라스트럭처 영역 : DB나 메시징 시스템 같은 외부 시스템 연동 처리 상위 계층에서 하위 계층으로의 의존만 존재 DIP 적용시 하위 기능을 추상화한 인터페이스는 고수준 모듈 관점에서 도출 도메인 영..