소개

DDD + CQRS의 맥락에서 컬렉션 조작에 대한 설명을 어디에 저장해야하는지 고민하고 있습니다.
나름대로 정리해 보았으므로 투고해 보겠습니다.

퍼스트 클래스 컬렉션은 객체 지향 운동의 단어입니다.
아키텍처는 양파 아키텍처에서 생각합니다.
도메인 서비스는 1 인터페이스 1 함수 1 기능인, 어디에도 속하지 않는 함수의 두는 장소라고 생각하고 있습니다.
애플리케이션 서비스는 비즈니스 지식 외부의 앱 특정 기능을 배치하는 곳이라고 생각합니다. (유스 케이스라든지)

1. 특정 조건과 일치하는 집계를 추출하고 싶습니다.

예를 들면 다음과 같습니다.

리포지토리에서 구현

특정 집계에 관한 것이므로 리포지토리에 담당하게 합니다. 하지만 리포지토리에는 영속화에 관한 것만에 전념해 주었으면 합니다. 퍼스트 클래스 컬렉션으로 구현

퍼스트 클래스 콜렉션을 준비해 거기에 조작을 기술합니다. 사용자가 대량으로 존재하면 힘들지도. 어느 정도 짜낸 요소에 대해 추가 조작을 할 때 편리할지도. 도메인 서비스로 구현

서비스로서 독립시켜 버립니다. 구현은 저장소를 통하지 않고 직접 저장 영역을 조작하는 것일 수 있습니다. 애플리케이션 서비스로 구현

검색의 조건은 업무 지식이 아닌 각 유스 케이스의 사정이라고 생각해, 어플리케이션 서비스에 두어 버립니다. 2. 특정 유스 케이스에 특화된 정보를 추출하고 싶습니다. 다음 도메인에서 생각합니다.

쿼리 (CQRS)로 구현

유스 케이스 전용 DTO와 쿼리를 준비하고 거기에 조건을 섞을 수 있습니다. 3. 집계를 넘은 검색 조건으로 매치한 집계를 추출하고 싶다 다음 도메인에서 생각합니다. 1:N로 연결되어 있는 느낌입니다.

이것이 가장 고민합니다. 집약적이기 때문에 리포지토리에 구현하는 것은 저항이 있습니다. 도메인 서비스로 구현

구현은 저장소를 통하지 않고 직접 저장 영역을 조작하는 것일 수 있습니다. 애플리케이션 서비스로 구현

검색의 조건은 업무 지식이 아닌 각 유스 케이스의 사정이라고 생각해, 어플리케이션 서비스에 두어 버립니다. 집계를 반환하는 기능이므로 쿼리에 저항이 있습니다. (CQRS) 요약 콜렉션 조작을 기술하는 장소에는 리포지토리 퍼스트 클래스 컬렉션 도메인 서비스 애플리케이션 서비스 쿼리 (CQRS) 거기 있다고 생각합니다. 이것은 원래 가지고 있는 컬렉션을 즐겁게 하는 이야기가 아니라 DB등 보존 영역으로부터 끌어올 때의 이야기입니다. 이미 가지고있는 컬렉션에 대해 조용한 경우 퍼스트 클래스 컬렉션 도메인 서비스 애플리케이션 서비스 그 자리에서 끈적 끈적한 설명 옵션이있을 것 같습니다. 퍼스트 클래스 컬렉션 public class 사용자 목록 { private List<사용자> 목록 => new List<사용자>(); public 사용자 목록 (IList <사용자> _ 목록) => 목록. AddRange (_ 목록); public IList<사용자> ごょんごょう() => } 도메인 서비스나 애플리케이션 서비스 public interface 고요한 서비스 { public IList<사용자> } 콜렉션 조작을 기술하는 장소는 어딘가에 통일하고 싶은 기분이 됩니다만, 그렇다면 도메인 서비스나 어플리케이션 서비스 밖에 없는 것입니다. 그렇게 되면 대량으로 서비스가 발생해 버려, 파악할 수 없게 되어 비슷한 검색 조건의 서비스가 완성될 것 같다. 결국 케이스 바이 케이스라든지 상황에 따라라고 밖에 말할 수 없을 것입니다만, 적어도 컬렉션 조작의 두는 장소의 후보의 정리에는 도움이 될지도. 어긋난 이야기를 하면 죄송합니다. 그 밖에도 좋은 두는 장소가 있으면 교시 바랍니다.