2 asked

0

최종적으로 조회된 결과가 한 두 엔티티로 매핑된다면 쿼리가 복잡해도 엔티티 조회가 가능합니다. 하지만 많은 경우엔 프로젝션을 통해서 여러 테이블의 필드를 조합해서 가져오게 되는데 이 때는 엔티티가 아닌 데이터 조회용 오브젝트(빈)을 선언해서 받아서 처리해야겠네요.

이렇게 조회하는 것이 단순 조회, 그러니까 조회 결과를 클라이언트에 리턴하는 것만 하면 된다면 리포트성 쿼리로 취급하면 됩니다.

그런데 이런 복잡한 조회 결과를 가지고 다시 도메인 로직을 적용해야 하는 경우도 있습니다. 이럴 때는 일정 패턴을 가진 조회 결과를 도메인 모델에 매핑하는 방법도 있습니다. 이때의 도메인 모델은 DB 테이블과 직접 매핑되지는 않지만 비즈니스로 의미가 있는 속성을 가지고, 로직을 적용하고, 필요하면 처리된 결과가 다시 데이터로 쓰여질 수도 있습니다. 도메인 모델을 잘 활용하는 방식으로 개발하면 이렇게 데이터 저장소의 데이터 구조와 다르지만 비즈니스적으로 의미가 있는 도메인 오브젝트를 설계할 수 있어야 합니다.

말씀하신 여러 팀이 같은 DB를 사용해서 우리 개발팀에서 DB를 쉽게 변경하기 힘든 경우, 또 우리가 만드는 시스템의 도메인 모델과 직접 매핑이 어려운 경우엔 잠깐 설명드렸던 도메인 모델과 데이터 모델을 분리하고, 리포지토리 어댑터에서 이를 매핑하는 방식이 유리할 수 있습니다.

0

안녕하세요, 인프런 AI 인턴입니다. test test님!

헥사고날 아키텍처와 도메인 모델 패턴을 실무에 적용하는 것은 상당히 좋은 선택입니다. 하지만 이미 DB 모델링이 완료되어 있고 여러 팀의 시스템이 동일한 테이블을 사용 중인 경우에는 몇 가지를 고려해야 합니다.

1. 여러 팀의 시스템이 같은 테이블을 바라볼 때 헥사고날 적용

헥사고날 아키텍처는 시스템과 외부 환경(예: 데이터베이스, 외부 시스템) 간의 느슨한 결합을 만들기 위해 설계된 패턴입니다. 여러 시스템이 같은 테이블을 사용할 때, 아래와 같은 방법을 고려할 수 있습니다:

• 도메인 모델의 독립성 유지: 각 팀이 자체적으로 도메인 모델을 정의하고, 필요에 따라 데이터베이스 테이블은 어댑터를 통해 접근합니다. 이 때, 각 팀의 어댑터가 실제 DB와의 상호작용을 캡슐화하고, 팀이 서로 다른 어댑터를 가질 수 있어야 합니다.

• API를 통한 데이터 접근: 데이터베이스에 대한 직접적인 접근을 줄이고, API를 통해 상호작용 함으로써 헥사고날 아키텍처의 ‘포트’와 ‘어댑터’ 개념을 활용할 수 있습니다. 이를 통해 데이터베이스 스키마 변경 시에 미치는 영향을 최소화합니다.

2. 여러 엔티티의 조합으로 리포트를 생성하는 경우

Query와 리포트 생성은 일반적인 도메인 모델의 로직과는 조금 다를 수 있습니다. 리포트는 특정 비즈니스 니즈를 충족시키기 위한 데이터 뷰이며, 다음 사항을 고려해보세요:

• 특정 ViewModel: 여러 테이블의 데이터를 조합하여 하나의 ViewModel 또는 DTO(Data Transfer Object)를 만들어 클라이언트에 반환합니다. 이 ViewModel은 특정 리포트에 맞게 설계되며, 여러 엔티티의 데이터를 담을 수 있습니다.

• 별도의 쿼리 서비스 설계: 복잡한 조회 로직은 별도의 쿼리 서비스를 통해 처리할 수 있습니다. 이는 도메인 모델의 변경 또는 비즈니스 로직과 분리되어 있어 유지보수성이 높습니다.

관련된 내용을 더 알고 싶다면 아래의 유사 질문을 참고하시면 도움이 될 것입니다:
- 헥사고날 아키텍처에서 복잡한 조회 처리 방법
- 여러 엔티티의 조합 리포트 만들기

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.