MSA, DDD 패턴으로 구현할때 고민사항

안녕하세요

2일동안 강의 달리면서 실습도 하면서 궁금증을 해소하기위해 달려온 잡부개발자입니다

최근 일반 레이어드 아키텍처로만 개발을 진행하니 생긴 문제들(테스트진행이 어려워짐, 소스파악하기 어려워짐 등등)이 생겨서 다른 아키텍처가 있나...찾아보다가 헥사고날 아키텍처가 가장 괜찮았다고 생각했고 DDD 형태로 진행하는게 깔끔할꺼같아서 혼자서 구조를 만들어보았어요
아래 설명을 이어붙히도록하겠습니다

adapter
ㄴ 헥사고날중 가장 바깥에 존재하는 controller, dao 부분
adapter-model
ㄴ adapter 에 쓰이는 모델들을 application 모듈과 연동시키기 위해 만든 model 클래스 모듈
application
ㄴ 각각의 UseCase 구현체와 인터펭이스가 존재하며 adapter-model 을 domain 객체로 변경하는 역할도 가진 모듈
domain
ㄴ 실제로 비즈니스로직을 가질수있는 POJO 도메인 객체

위 구조는 Aggregate 를 적용하지않았기때문에 향후 각각의 작은 서버로 구성할수있는 MSA 로 뺄수있는 구조는 아니에요 다만 그건 aggregate 모듈을 만들어서 빼면 되는거라 생각하는데 그것보다도 가장 궁금한점은..... 비즈니스 로직을 POJO 객체가 있는 domain 모듈로 파싱할때 JPA 기준 A 라는 유저가 가지고있는 게임플레이 히스토리들도 가지고있잖아요?
이건 POJO 객체로 가져올때 히스토리 객체들도 모두 가지고와서 POJO 내에 넣어야하나요?
반대의 경우 히스토리에서는 유저객체를 들고있을텐데 이때 의존을 모두 가져와야하나요? 아니면 유저의 키값만 객체로 들고있으면될까요?

만약 해당 유저가 한시간에 1000번의 게임을 했다고 가정하면 몇일만 조회해도 엄청 많은 데이터가 램으로 올라가기때문에 좀 부담스러운데 히스토리가 필요한경우 쿼리에 비즈니스로직을 담아 타협해야하나요?
물론 드라마틱한 성능차이가 없다면 도메인에서 처리해도되겠지만 성능상 차이가 많이 난다면 쿼리에 비즈니르로직을 담아야하는게 아닌가싶어서요

글이 좀 생각의 흐름대로 쓰인거같아 미리 죄송합니다 ㅠ