DDD 스터디

현실 세계에 있는 사물이나 현상 등을 소프트웨어로 해결하고자 하는 문제 영역한 도메인은 다시 하위 도메인으로 나눌 수 있다.제품 개발과 관련된 전문가, 관계자, 개발자가 같은 지식을 공유하고 직접 소통할수록 도메인 관계자가 원하는 제품을 만들 가능성이 높아진다.개발자는

표현 영역HTTP 요청을 응용 영역이 필요로 하는 형식으로 변환해서 응용 영역에 전달하고 응용 영역의 응답을 HTTP 응답으로 변환하여 전송한다.응용 영역로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임한다.도메인 영역도메인의 핵심 로직을 구현한다.인프라스터럭

도메인 객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다.→ 코드를 변경하고 확장하는 것이 어려워진다.해결 방법관련된 객체를 하나의 군으로 묶어 준다.수많은 애그리거트로 묶어서 바라보면

리포지터리 기본 기능 ID로 애그리거트 조회하기애그리거트 저장하기스프링 데이터 JPA지정한 규칙에 맞게 리포지터리 인터페이스를 정의하면 리포지터리를 구현한 객체를 알아서 만들어 스프링 빈으로 등록해줌리포지터리 인터페이스를 직접 구현하지 않아도 됨엔티티와 밸류 기본 매핑

검색 질의문을 나타내기 위해서는 필요한 조합마다 find 메서드를 정의해야한다.이때의 문제는 조합이 증가할수록 정의해야 할 find 메서드가 함께 증가하는 문제가 발생한다.이렇게 검색 조건을 다양하게 조합해야 할 때 사용할 수 있는 것이 스펙이다.스펙 : 애그리거트가

표현 영역 : 사용자의 요청을 해석한다.응용 서비스 : 실제 사용자가 원하는 기능을 제공한다.사용자가 웹 브라우저를 사용하는지 REST API를 호출하는지, TCP 소켓을 사용하는지를 알 필요가 없다.도메인 객체를 사용해서 사용자의 요청을 처리하는 것이므로 표현 영역

애그리거트에 넣기 애매한 도메인 기능을 억지로 특정 애그리거트에 구현하면 안된다.억지로 구현하면 애그리거트는 자신의 책임 범위를 넘어서는 기능을 구현하기 때문에 코드가 길어지고 외부에 대한 의존이 높아지게 되며 코드를 복잡하게 만들어 수정을 어렵게 만드는 요인이 된다.

트랜잭션 처리 방식선점 방식 (비관적 락) 2. 비선점 방식 (낙관적 락)한 트랜잭션에서 쓰기를 하는 동안 다른 트랜잭션에서는 잠금으로 대기JPA에서는 EntityManager는 LockModeType을 인자로 받는 find()메서드르 제공함for update 쿼리를

모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖는다. 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 서로 다르다.DDD에서는 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트라고 부른다.여러 하위 도메인을 하나의 바운디드 컨텍스트에서 개발할 때 주의

주문 서비스 + 결제 서비스(외부)외부 서비스가 정상이 아닐 경우 트랜잭션 처리를 어떻게 해야할까?성능에 대한 문제 → 외부 서비스 성능에 직접적인 영향을 받게 됨→ 주문 바운디드 컨텍스트와 결제 바운디드 컨텍스트 간의 강결합 때문→ 해결 방법 : 이벤트를 사용하는 것

시스템이 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기 때문객체 지향으로 도메인 모델을 구현할 때 주로 사용하는 ORM 기법은 도메인 상태 변경 기능을 구현하는 데는 적합하지만 주문 상세 조회 화면처럼 여러 애그리거트에서 데이터를 가져와 출력하는 기능을 구