CQRS - read 에서의 DDD 설계에 대해

Question

현재 DDD를 메인 철학으로 개발 프로젝트를 진행하고 있는데, 프로덕트 사이즈가 커지면서 클라이언트에 맞는 구체적인 조회 모델 제공에 대한 필요가 커져 별도의 쿼리 서비스를 만드는 작업을 하고 있습니다. 원래 사용하던 아키텍처는application(usecase 등)presentation(rest controller)infrastructure(repo & mapper)domain(aggregateRoot, VO 등)요렇게 두고 domain의 AggregateRoot를 각 계층별 dto에 실어담아 작업을 진행했습니다. infra까지 도달한 aggregateRoot는 이벤트를 발행하고, db에 저장된후 다시 orm model -> domain model로 변환된후 전달되는 느낌으로요.다만 쿼리쪽의 경우엔 도메인? aggregateRoot? 라는 별도의 레이어의 필요성이 적어지다 보니 일단 레이어적으로는applicationpresentationinfrastructure도메인 없이 이렇게 가도 충분히 로직 수행은 가능합니다만, 도메인레이어의 부재로 각 레이어 사이에 주고받을 dto 설계가 굉장히 애매해졌습니다. 그래서 공용 클래스를 하나 두고 싶은데 이걸 도메인 레이어안에 넣기도 그렇고 참 애매해서 질문 올립니다. 질문의 요는 3가지 입니다.Query 시 command의 aggregateRoot class처럼 계층 간 사용가능한 공용의 클래스를 두는 지그렇다면 그 클래스의 이름은? (responseModel? , projection? 등)그 클래스가 담긴 계층 이름은?혹은 다른 방식의 쿼리 서비스 설계에 대해서 공유해주셔도 정말 감사할것 같습니다..! 굳이 query에 클린아키텍처니 ddd니 적용하면서 자꾸 꼬이는거 같은 생각이 드네요.

집킨 · Accepted Answer

CQRS의 READ에는 aggregate 개념이 없는게 일반적이기 때문에 그냥 application layer에 DTO만들고 그거 쓰시면 됩니다전 이럴때 이름은 xxxResponse 로 씁니다

CQRS - read 에서의 DDD 설계에 대해

1개의 답변

Q&A 목록