ddd start

3개월간 프로젝트를 진행하면서 꾸준히 읽어온 책을 정리해보려 한다. 책이 절판돼서 도서관을 여러곳 들려 찾았다...! 살 수 있음 좋겠는데..ex) 온라인 서점을 통해 책을 구매한다.개발자의 입장에서 온라인 서점은 구현해야 할 대상이 된다.온라인으로 책을 판매하기 위

아키텍처를 설계할 때 출연하는 '표현' , '응용' , '도메인' , '인프라스트럭처'의 네 영역이다.표현 영역을 통해 사용자의 요청을 전달받은 응용영역은 시스템이 사용자에게 제공해야 할 기능을 구현한다.응용서비스는 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을

복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들기 위해 상위 수준에서 모델을 조망할 수 있는 방법이다.애그리거트는 관련된 객체를 하나의 군으로 묶어준다.애그리거트 단위로 일관성을 관리하기 때문에 복잡한 도메인을 단순한 구조로 만들어주며, 복잡도가 낮아지는 만큼 도메

가능하면 리포지토리 구현 클래스를 인프라스트럭쳐 영역에 위치시켜서 인프라스트럭쳐에 대한 의존을 낮춰야한다.애그리거트 루트는 엔티티이므로 @Entity 로 매핑설정한다.한 테이블에 엔티티와 밸류 데이터가 같이 있다면밸류는 @Embeddable로 매핑설정한다.밸류타입 프로

리포지토리는 애그리거트의 저장소이다. 애그리거트를 찾을 때 식별자를 이용하는 것이 기본이지만 식별자 외에 여러 다양한 조건으로 애그리거트를 찾아야 할 때가 있다.검색 조건의 조합이 다양할 경우 스펙을 이용해서 문제를 풀어야 한다.스펙은 애그리거트가 특정 조건을 충족하는

도메인 영역을 잘 구현하지 않으면 사용자의 요구를 충족하는 제대로 된 소프트웨어를 만들지 못한다.그러나 도메인 영역만 잘 만든다고 끝나는 것이 아닌, 도메인이 제 기능을 하려면 사용자와 도메인을 연결해주는 매개체가 필요하다.(응용 영역)실제 사용자가 원하는 기능을 제공

한 애그리거트에 넣기에 애매한 도메인 기능을 특정 애그리거트에서 억지로 구현하면 안된다.이 경우 애그리거트는 자신의 책임 범위를 넘어서는 기능을 구현하기 때문에 코드가 길어지고 외부에 대한 의존성이 높아지게 된다.이를 해결하기 위해서 도메인 서비스를 별도로 구현하면 된

2개 이상의 트랜잭션을 동시에 실행시켜 데이터를 수정할 경우, 트랜잭션 실행시점에서 애그리거트의 일관성이 깨질 경우가 발생한다.DBMB가 지원하는 트랜잭션과함께 애그리거트를 위한 추가적인 트랜잭션 처리 방식이 필요하다선점(Pessimisic) 잠금비선점(Optimist

모델은 특정한 컨텍스트 하에서 완전한 의미를 갖는다같은 제품이라도 카탈로그 컨텍스트와 제고 컨텍스트에서 의미가 서로 다르다.이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 BOUNDED CONTEXT라고 부른다.BOUNDED CONTEXT는 모델의 경계를 결정하며

환불 기능을 실행하는 과정에서 Exception이 발생하면 트랜잭션을 롤백해야할까? 아니면 일단 커밋을 해야할까?외부 시스템이 정상이 아닐 경우, 트랜잭션 처리를 어떻게 할지 애매하다는 것이다. 환불 실패시 반드시 트랜잭션을 롤백하는 것은 아니다. 주문은 취소 상태로

여러 애그리거트에서 데이터를 가져와야 할 경우, 애그리거트를 참조하는 방식을 사용하면 즉시 로딩과 같은 JPA의 쿼리 관련 최적화 기능을 사용할 수 없다.애그리거트 간의 연관을 ID가 아니라 직접 참조하는 방식으로 연결해도 고민거리가 생긴다.CQRS는 Command Q