헥사고날 아키텍처와 DDD를 적용할 때, 화면에 강하게 연관된 조회 데이터를 어떻게 다루는 게 좋은지 궁금합니다.

Question

헥사고날 아키텍처와 DDD를 적용할 때, 화면에 강하게 연관된 조회 데이터를 어떻게 다루는 게 좋은지 궁금합니다. 예를 들어 채팅방 목록 화면에서 각 채팅방마다 다음 정보를 한 번에 보여줘야 한다고 가정하겠습니다 . ex) 채팅방 이름, 마지막 채팅 내용, 읽지 않은 채팅 개수 이 정보를 구하려면 room, chat, read_status 같은 여러 테이블을 함께 조회해야 하고 , N+1 문제를 피하려면 Querydsl 이나 JDBC 등을 사용해서 한 번의 쿼리로 조회하는 방식이 필요해 보입니다 . 이 경우 제 생각에는 기존 포트와 분리해서 , 조회 전용 port 와 query repository interface 를 application 계층에 두고 , adapter 계층에서 Querydsl/JDBC/MyBatis 등으로 구현하는 것이 해결책 같습니다. 이런 식으로 cqrs패턴을 적용하는 것이 유일한 해결책인가요? 혹시 더 나은 방법이 있는지 궁금하여 질문남깁니다. (강의 너무 잘 보고 있습니다)

communityai8509 · Answer

안녕하세요, 인프런 AI 인턴입니다. jayuffh22님! 채팅방 목록 화면에서 다양한 정보를 효율적으로 조회할 때, 헥사고날 아키텍처와 도메인 주도 설계(DDD)를 고려하다 보면 당신이 제안한 방법, 즉 CQRS(명령 및 조회의 책임 분리) 패턴을 사용하는 것이 매우 합리적이며 일반적으로 추천되는 접근 방식입니다. 하지만, CQRS 패턴이 유일한 해결책은 아닐 수 있으며, 프로젝트의 규모와 복잡도에 따라 다른 접근 방식도 고려해볼 수 있습니다. 몇 가지를 소개해드리겠습니다: 조회 전용 포트 및 쿼리 리포지토리의 사용 : CQRS 패턴의 장점은 조회 성능을 최적화하면서 도메인 모델을 변경으로부터 보호할 수 있다는 것입니다. 조회 전용 포트를 어플리케이션 계층에 두고, 구현을 어댑터 계층에서 다루는 방식은 좋은 설계입니다. 이 방법을 통해 여러 테이블을 조인하여 한 번에 데이터를 가져올 수 있으며, 복잡한 데이터 조회 로직이 도메인 모델에 영향을 미치지 않도록 설계할 수 있습니다. 최적화된 조회를 위한 뷰 모델 사용 : 도메인 모델로부터 데이터를 직접 가져오지 않고, 화면에 필요한 데이터를 별도의 뷰 모델(View Model)로 처리할 수 있습니다. 이는 화면에 필요한 데이터를 쉽게 제공하면서 비즈니스 로직의 복잡성을 줄이는 방법 중 하나입니다. 데이터베이스 관점에서의 최적화 : SQL 쿼리를 최적화하거나, 데이터베이스 인덱스를 활용하여 성능을 향상시키는 방법도 있습니다. 이 경우, 데이터베이스의 특정 기능이나 확장성에 따라 성능을 최적화할 수 있습니다. 캐싱 : 잦은 조회가 필요한 데이터에 대해서는 캐싱을 활용하여 성능을 높일 수 있습니다. 캐시 시스템을 통해 자주 조회되는 데이터를 미리 저정해두면, 데이터베이스 조회를 줄이고 전체 시스템의 응답성을 향상시킬 수 있습니다. 위의 방법들은 각각의 장단점을 가지고 있으며, 사용 사례에 맞는 최적의 접근 방법을 선택하는 것이 중요합니다. CQRS는 특히 복잡한 도메인에서 효과적이지만, 모든 프로젝트에 적합한 것은 아니므로 다른 방법도 함께 고려해보시는 것을 추천드립니다. 제가 추천드리는 접근 방법에 대한 유사한 질문과 토론을 아래에서 확인할 수 있습니다: 데이터 조회 성능 최적화에 대한 질문 CQRS 패턴 적용의 이해 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.