어플리케이션 서비스와 도메인 서비스의 구성

안녕하세요.

OSIV 강의 후반부 내용에서 규모가 비교적 큰 프로젝트에서는 도메인 계층과 더불어 그 앞단에 애플리케이션 계층을 추가하는걸 고려해보라고 말씀주신 내용이 있었는데요. 이게 제가 찾고 있는 해답이 아닐까 싶어 조금 더 자세히 알고 싶어 질문 드립니다. 질문이 조금은 장황해도 너그러히 이해주시면 감사드리겠습니다.

최근에 개인 프로젝트를 수행해보면서 제가 학습해온 개념들(JPA, DDD, MSA)이 중점적으로 다루는 내용이 다르다보니 프로젝트 구성에서 혼란을 겪어오고 있습니다.

현재 개인 프로젝트 패키지 구조는 제가 느끼기에 가장 와닿았던 controller - application - domain - repository로 나뉘어 개발하고 있습니다.

이때 application 계층의 역할은 하나의 요구사항(가입, 해지 등)을 해결하기 위해 필요한 하위 계층의 애플리케이션 서비스들을 호출하는 facade를 구성합니다. 또, domain에서는 도메인 객체와 더불어 해당 도메인의 애플리케이션 서비스를 통해 비즈니스적 처리를 추상화하여 표현하고, 데이터 핵심 데이터 처리를 repository에 위임하도록 구성했습니다.

다만 이해가 안 갔던건 트랜잭션을 처리 계층에 대한 내용인데요. 제가 본 msa 도서에서는 facade에서 수행되는 애플리케이션 서비스 각각이 서로 다른 도메인 처리이므로 application 계층이 아닌, domain 메소드 단위로 트랜잭션이 구성되어야한다더라구요.

그런데 사실 제가 개발하고 있는 프로젝트는 MSA 구조가 아니고, 여러 에그리거트가 복합된 구조이기에 위 구조와 사상을 가지고 개발하기 어렵다는 생각이 들었습니다. 또한, 서로 다른 도메인의 애플리케이션 서비스간에 호출관계에서도 어려움을 겪었는데요.

예를 들어, 두 user가 하나의 group을 구성하는 서비스를 만들 때도 groupService라는 group에 종속된 애플리케이션 서비스에서 두 사용자 정보를 불러오는 userService 주입하자니, 서로 상이한 서비스간에 불필요한 의존성이 생기고, 같은 레벨의 서비스를 참조하는 것이 어색하다고 느껴졌습니다. 그래서 facade 계층에서 두 서비스를 주입하여 그룹생성 절차를 처리하자니 한 트랜잭션에 처리되어야한다고 생각하는 그룹 생성 처리 절차에서 회원, 그룹 서비스의 트랜잭션이 분리되니 이상하다고 생각했습니다.

드디어 본격적인 질문인데요.

1. 혹시 영한님께서 말씀하신 애플리케이션 계층이 이렇게 도메인에 종속된 두 개 이상의 서비스가 함께 쓰여야 할 때 쓰이는 것이 맞을까요?

2. 맞다면 controller - application - domain - repository 의 계층구조에서 facade가 들어가던 application에 해당 복합(?) 서비스를 구현하고, 해당 서비스에 대한 dto객체정도들만 구현하면 되는걸까요?

 3. 굳이 어플리케이션 계층이 필요로 하지않은 하나의 도메인에만 종속된 기능들을 호출구조를 어떻게 가야할까요?

애플리케이션 계층을 도입한 상황에서 controller에서 domain 계층을 바로 호출하는 것은 일관성이 없어보이고, 또 일관성을 맞추기위해 application 계층에서 도메인 계층으로 BYPASS하는 객체를 만드는 것도 비효율적으로 보이긴합니다. 각각의 케이스에 어떻게 가는게 좋을까요?