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

Question

안녕하세요 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번의 게임을 했다고 가정하면 몇일만 조회해도 엄청 많은 데이터가 램으로 올라가기때문에 좀 부담스러운데 히스토리가 필요한경우 쿼리에 비즈니스로직을 담아 타협해야하나요? 물론 드라마틱한 성능차이가 없다면 도메인에서 처리해도되겠지만 성능상 차이가 많이 난다면 쿼리에 비즈니르로직을 담아야하는게 아닌가싶어서요 글이 좀 생각의 흐름대로 쓰인거같아 미리 죄송합니다 ㅠ

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴이에요. MSA와 DDD 패턴을 결합하여 구현해보려는데 고민 사항이 있으신 것 같아요. 일반 레이어드 아키텍처에서 발생한 문제들로 인해 다른 아키텍처를 찾아보고, 헥사고날 아키텍처와 DDD 형태를 적용하려고 하신다고 이해했습니다. 헥사고날 아키텍처는 소프트웨어의 분리와 테스트 가능성을 높이기 위한 아키텍처 패턴입니다. DDD은 도메인 주도 설계로, 도메인 지식과 비즈니스 규칙에 중점을 둔 소프트웨어 개발 접근 방식입니다. adapter, adapter-model, application, domain 모듈로 구성될 것 같은데, 비즈니스 로직을 POJO 객체가 있는 domain 모듈에 구현하는 것이 궁금하시다고 말씀하셨네요. 비즈니스 로직을 POJO 객체에 구현하는 것은 DDD에서 중요한 개념 중 하나입니다. 도메인 객체는 비즈니스 로직을 담은 객체로, 도메인의 규칙과 동작을 표현합니다. 따라서 비즈니스 로직은 domain 모듈에 구현하는 것이 바람직합니다. 하지만 좀 더 구체적인 내용을 알아야 정확한 답변을 드릴 수 있을 것 같아요. 구체적으로 어떤 고민 사항이 있으신지 자세한 설명을 부탁드립니다. 도움을 드릴 수 있도록 최대한 노력하겠습니다.