DDD 저장소 입력 매개 변수

Question

다음 예에서 _customRoleRepository을 구현하는 데 권장되는 방법은 무엇입니까? 응용 프로그램 서비스에서 다음 코드가 실행됩니다.

var user = _userRepository.GetById(1); 
var customRole = _customRoleRepository.GetById(user.CustomRoleId); 

또는

var user = _userRepository.GetById(1); 
var customRole = _customRoleRepository.GetForUser(user); 

Answer 1

주어진 두 가지 옵션을 사용하면 ID로 액세스하는 일관성을 유지하는 첫 번째 옵션으로 전환 할 수 있습니다.

특히 사용자가 데이터베이스를 왕복하지 않도록 사용자를로드 할 때 사용자 지정 역할을로드하는 것이 좋습니다 (특히 일반적인 작업 인 경우). 이것은 읽기 모델로 구현 될 수 있습니다.

이

Answer 2

증오는 대답하지만 DDD 환경에서, 내 대답은 '아니 될 것입니다.

첫 번째 예에서는 역할 저장소가 사용자 도메인을 잘 모르는 경우가 있지만 응용 프로그램이 사용자의 ID를 가져 와서 다른 저장소를 쿼리하는 데 필요한 역할을 알아야한다는 것을 의미합니다 . 즉, 응용 프로그램은 사용자와 역할 사이의 매퍼 (mapper) 역할을합니다.

두 번째 예에서 역할 저장소는 이제 사용자 도메인에 대해 알아야합니다. 그다지 좋지는 않지만 다른 한편으로 애플리케이션은 더 이상 roleId에 대해 알 필요가 없습니다. 그래서 그것은 좋다. 두 가지 접근 방식 사이의 고전적인 거래.

두 경우 모두 응용 프로그램은 정보를 얻기 위해 여전히 두 개의 저장소가 필요합니다. 더 많은 관계가 필요할 때 어떻게됩니까? 리포지토리의 수는 빠르게 증가하고 모든 것이 엉망이됩니다.

도메인 기반 디자인에서는 집계 루트 (AR)와 도메인 컨텍스트를 고려해야합니다. 예제 컨텍스트에서 사용자는 AR이고 역할은 하위가됩니다. 그래서 당신이있을 수 있습니다

하면 응용 프로그램에서 구현 세부 사항의 대부분을 숨기고 도메인 엔티티가 실제로 무엇을해야하는지에 초점을 맞출 수

var user = _userFinder.GetById(1); 
var customRole = user.CustomRole; 

.

Answer 3

: ... 당신이 제대로 집계를 모델로 한 추정되고 모두 필요에 따라 동일하게 유효합니다. GetForUser은 역할을 시도하기 전에 호출 코드에 유효한 User 집계가 있는지 확인하려는 경우 유용 할 수 있습니다. 호출 코드가 유효한 코드를 요구하도록하려면 customRoleRepository와 User 집계를 연결해야합니다. 사용자 집합체는 그 커플 링에 목적이 있습니다.

GetByUserId은 GetById 더 일관성이 적은 커플 링이 있으므로 클라이언트가 유효한 사용자 집합이없는 경우에도 사용자의 컨텍스트에서이 GetByUserId를 호출 문제가되지 않는 경우에, 그 너무 괜찮아요.

당신이 ById을로드하는 경우, 나는 또한 안전한 형태의 추가 수준의 제공에 매우 도움이 될 수있는 입력 신원 valueobjects를 사용하여 발견 한 - 여기 찬반 여기 단점 https://stackoverflow.com/a/5377460/6720449에 대한 몇 가지 대화와 https://groups.google.com/forum/#!topic/dddcqrs/WQ9zRtW3Gbg