2

데이터 레이어에 액세스하려면 스프링 데이터 JPA 을 사용하는 Spring 애플리케이션을 개발 중입니다.Spring Data JPA를 사용하여 DOMAIN-DRIVEN DESIGN 아키텍처를 얻으려면 어떻게해야합니까?

@Repository 
@Transactional(propagation = Propagation.MANDATORY) 
public interface EntityType1DAO extends JpaRepository<EntityType1, Long> { 

    //@Query("FROM Room WHERE accomodation = :id") 
    List<EntityType1> findByEntityType1(EntityType1 entityType1); 

} 

@Repository 
@Transactional(propagation = Propagation.MANDATORY) 
public interface EntityType2DAO extends JpaRepository<EntityType2, Long> { 

    List<EntityType2> findByEntityType2(EntityType2 entityType2); 

} 

........................................................................... 
........................................................................... 
........................................................................... 

@Repository 
@Transactional(propagation = Propagation.MANDATORY) 
public interface EntityTypeNDAO extends JpaRepository<EntityTypeN, Long> { 

    List<EntityTypeN> findByEntityTypeN(EntityTypeN entityTypeN); 

} 

을 그래서 기본적으로이에서 :

그래서 기본적으로 내가 엔티티 클래스에 관련된 데이터베이스 테이블의 데이터에 액세스 할 수 n 개의 엔티티 클래스N 관련 저장소 클래스, 이런 일이 방법은 n 도메인 클래스 ** n 저장소 클래스에 의해 액세스했습니다.

이 두 도메인 클래스을 공통 개념에 속하는 하위 집합으로 나눌 수 있습니다. , RoomTipologyRoomRateRoomPicture 모두 룸 개념에 속하는 :

예를 들어 내가 좋아하는 엔티티 클래스를 가질 수 있습니다.

그래서 나는 다음과 같은 서비스 클래스를 갖게됩니다 RoomDAO, RoomTipologyDAO, RoomRateDAORoomPictureDAO.

잘 작동하지만 좀 더 DOMAIN-DRIVEN DESIGN 아키텍처를 채택하고 싶습니다.

그래서 나는 봄 응용 프로그램에서 도메인 주도 설계을 구하는 방법에 대한 흥미로운 기사를 발견했다 : http://static.olivergierke.de/lectures/ddd-and-spring/

는 말한다 이전 기사를 읽고 그 :

저장소 - 봄의 구성 요소, 일반적으로 스프링 데이터 저장소 인터페이스입니다. 엔티티와 값 객체에 의존 할 수 있으며, 집계 루트 인 엔티티는 에 집중됩니다.

정확히 무엇을 의미합니까? 내가 (함께 집계 그 예를 RoomAggregation, RoomTipologyRoomRateRoomPicture 엔티티 클래스)를 집계 뿌리를 클래스를 만들 수 있다는 것을 의미 @Embedded 주석을 사용하여.

또는 무엇? 스프링 데이터 JPA를 사용하여 내 응용 프로그램에서 도메인 주도 설계을 얻을 수있는 좋은 건축 해결책이 될 수 무엇

?

+0

DDD에서 다른 내용을 읽었습니까? 하나의 매우 간결한 기사에 포함 된 지식에 대한 전체적인 아키텍처 변화를 기반으로하는 것이 가장 좋은 아이디어는 아닙니다. – guillaume31

답변

2

새 클래스를 집계로 만들지 마십시오.대신 당신은 기존의 것을 선택합니다. 일반적으로 그것은 자체를 제시하고 귀하의 예에서는 귀하의 예가 될 수 있습니다. Room

그러면 리파지토리 (RoomRepository 또는 Rooms 어쩌면)에 대한 저장소가 있습니다. 필요한 다양한 기준에 따라 방을 찾는 등 방을 저장하고로드하는 데 사용합니다. 예 A RoomPicture에 대한 액세스

위해 (조작은) 당신은 RoomPictureRoom 탐색이 그것을 조작하고 본질적으로 객실을 수정하는 것을 의미하여 JPA 세션을 저장,로드 할 수 있습니다.

엔티티 (@OneToMany 및 갱) 간 간단한 탐색을 선택하거나 @Embedded ist는 선택한 집계의 영향을받지 않습니다. 단, 집계에서 직접 참조를 가지지 않은 경우는 예외입니다. 따라서 Booking도 AggregateRoot로 가지고 있다면 BookingroomId이 될 것이고 Room Repository를 사용하면 Room을 보게 될 것입니다.

0

우선 Spring Data JPA 또는 다른 지속성 메커니즘을 잊어 버리십시오. 도메인 기반 디자인 (Domain Driven Design)은 분석에서 도메인을 모델링하는 것이고 특정 사례는 일종의 호텔 하위 도메인을 모델링하는 것과 관련되며 전혀 지속성에 대해 걱정하지 않습니다. 그것은 호텔과 관련이 없지만 지속성 (다른 도메인 또는 경계 된 상황)과 관련된 또 다른 완전히 다른 관심사입니다.

우리는 행동을 식별 할 수 있도록 개념 대신 유스 케이스의 관점에서 생각해야하며 이렇게하면 항상 일관성을 유지해야하는 경계를 설정하는 데 필요한 불변량을 감지 할 수 있습니다.

Vaughn이 제안한 것처럼 작은 집계를 모델링해야합니다. 큰 집계를 갖는 것이 좋지 않다는 것을 기억하십시오. 호텔 매니저는 Room을 인스턴스화하여 실제로 Room을 표현하고 번호 및 기타 물건을 제공 할 수 있습니다. 이제 가격과 사진은 어떻습니까? 가격의 예를 들어 보겠습니다. 가격이 얼마인지 방이 실제로 알 수 있습니까? 객실 가격이 다이나믹하고 완전히 날짜와 같은 다른 많은 변수의 영향을받지 않습니까? 방 집계에서 요금을 수정해야하는 이유는 무엇입니까? 우리는 현실 세계에서 그러한 책임에 대해 책임을지지 않는 방이 있고 가격은 방의 경계 밖에서 발생하는 몇 가지 조건에 의해 영향을 받았다고 말했습니다. 따라서 요금은 철저한 방에서 우연한 것입니다. 철학 용어로 말하면 필수는 아닙니다.

다른 집계는 PriceList이며 동일한 이름을 가진 집계입니다. 그래서 특정 날짜에 가격표, 객실 가격 (표준, 디럭스, ...)을 물어 볼 수 있으며 가격은 알 수 있습니다 :) 이 모든 것들을 어떻게 모델링 했느냐에 따라 이것은 가격이 책정 된 컨텍스트가 Microservice로 노출되었지만 걱정하지 않아도됩니다. PriceList는 룸에서 완전히 격리 된 또 다른 집계이며 룸 번호 인 개념 아이덴티티로 룸을 참조합니다.

동일한 내용이 RoomPicture에 적용됩니다. 이 특별한 경우에는 앨범 사진을 다루는 부서/지역/직원이 관리자가 아니라 다른 역할을 담당하고 자신의 라이프 사이클이 포함 된 방 앨범을 만드는 다른 사람이 될 수 있다고 생각하십시오.

당신이이 집계 가진 끝낼 것 conclusiong으로

:

룸 가격표를 앨범

을 그리고 방 번호 (없는 방)을 참조하는 모든 연결 한 연결을 기억하고 각 불변의 주위에 자신의 경계를 가지고 . 거대한 응용 프로그램에서 각각의 고유 한 상황에서 생존 할 수 있습니다.

기억 룸은 사진 앨범이나 가격표를 통해서도 불변의 것을 나타내지 않습니다.

호프가 도움이 되었으면 좋겠다. 세 바스 챤.

0

@Sebastian이 매우 잘 설명해 주었기 때문에 응용 프로그램을 DDDing 할 때 지속성이 가장 걱정되는 요소입니다. 엔티티를 데이터베이스와 결합시키지 마십시오. 그렇지 않으면 ddd로 엉망이되는 데이터베이스 기반의 응용 프로그램으로 끝날 것이며 깨끗한 코드와 미적인 측면에서 볼 수 없습니다. 데이터베이스 기반 정신을위한 도메인 기반 디자인이라는 유튜브에 좋은 프레젠테이션이 있습니다.

두 번째로 대부분의 DAO는 값 객체로 리팩토링되어야하며 비즈니스 객체를 값 객체 및 엔티티에 덤핑해야합니다. 결국에는 객체를 저장하는 것에 대해 걱정할 필요가있을 때 데이터 매퍼 계층으로 이동하십시오.

경험에 비추어 말하면, 가치 객체가 올바르게 완료되면 적절한 앱 디자인이 90 % 가중됩니다.