DDD

도메인, domain소프트웨어로 해결하고자 하는 문제 영역하나의 도메인은 여러 개의 하위 도메인으로 나눌 수 있다. 예를 들어,온라인 서점 도메인은 카탈로그, 회원, 주문, 정산, 배송 과 같이 하위 도메인으로 나눠진다. 하나의 하위 도메인은 다른 하위 도메인과 연동하

네 개의 영역 다음은 아키텍처를 설계할 때 출현하는 전형적인 네 가지 영역에 해당한다. |영역|역할| |:-|:-| |UI, Presentation|사용자의 요청을 받아 응용 영역에 전달하고, 응용 영역의 처리 결과를 다시 사용자 (= 웹 브라우저의 사용자, RES

시스템을 개발할 때, 상위 수준 개념을 이용해서 전체 모델을 정리하면 도메인 모델의 복잡한 관계를 전반적으로 이해하는 데 도움이 된다.상위 수준에 대한 이해 없이 상위 수준에서 개념을 파악하려면 오랜 시간이 걸린다.더 많은 코드를 보고 도메인 전문가와 더 많은 대화를

이 장의 주제는 Repository 구현이다.애그리거트를 어떤 저장소에 저장하느냐에 따라 구현 방법이 다르기 때문에 모든 구현 기술에 대해 알아볼 수는 없다.데이터 보관소로 RDBMS를 사용할 때, 객체 기반의 도메인 모델과 관계형 데이터 모델 간의 매핑을 처리하는 기

시작에 앞서 언급할 것이 하나 있다. 바로 CORS 이다.CORS 는 명령 모델과 조회 모델을 분리하는 패턴이다.명령 모델은 상태를 변경하는 기능을 구현할 때 사용하고, 조회 모델은 데이터를 조회하는 기능을 구현할 때 사용한다.예를 들어,회원 가입, 암호 변경처럼 상태

도메인 영역을 잘 구현하는 것은 사용자의 요구를 충족하는, 제대로 된 소프트웨어를 만드는 데에 기본이 된다.하지만 도메인 영역만 잘 만든다고 끝나는 것은 아니다!도메인이 제 기능을 하려면 사용자와 도메인을 연결해주는 매개체가 필요한데, 이러한 매개체 역할을 하는 것이

도메인 영역의 코드를 작성하다 보면, 한 애그리거트로 기능을 구현할 수 없을 때가 있다.대표적인 예가 결제 금액 계산 로직이다.실제 결제 금액을 계산하기 위해 다음과 같은 내용이 필요하다.상품 애그리거트 : 구매하는 상품 가격, 상품의 배송비가 필요주문 애그리거트 :

하나의 주문 애그리거트에 대해 운영자는 배송 상태로 변경을, 사용자는 배송지 주소를 변경하면 어떻게 될까?트랜잭션마다 리포지토리는 새로운 애그리거트 객체를 생성하므로 운영자 스레드와 고객 스레드는 같은 주문 애그리거트를 나타내는 다른 객체를 구하게 된다. 운영자 스레드

처음 도메인 모델을 만들 때 빠지기 쉬운 함정이 도메인을 완벽하게 표현하는 단일 모델을 만드는 시도를 하는 것이다.한 도메인은 다시 여러 하위 도메인으로 구분되기 때문에 한 개의 모델로 여러 하위 도메인을 모두 표현하려고 시도하면 오히려 모든 하위 도메인에 맞지 않은

쇼핑몰에서 구매를 취소하면 환불을 처리해야 한다.이때 환불 기능을 실행하는 주체는 주문 도메인 엔티티가 될 수 있다.도메인 객체에서 환불 기능을 실행하려면 환불 기능을 제공하는 도메인 서비스를 파라미터로 전달받고 취소 도메인 기능에서 도메인 서비스를 실행하게 된다.응용

조회 화면은 특성상 조회 속도가 빠를수록 좋은데, 여러 애그리거트의 데이터가 필요하면 구현 방법을 고민해야 한다.식별자를 이용해서 애그리거트를 참조하는 방식을 사용하면 즉시 로딩과 같은 JPA 쿼리 관련 최적화 기능을 사용할 수 없다.이는 한 번의 SELECT 쿼리로