뒤늦은 깨달음 Appication VS Domain

🧠 이번 주에 새로 배운 것

이전까지 나는 계층형 아키텍처를 단순히 패키지 구조를 나누는 것이라고 막연하게 생각했다.
Controller, Service, Repository... 늘 쓰던 구조였지만, "그래서 Service는 정확히 무슨 일을 해야 하는가?" 라고 물으면
명확하게 답하기 어려웠다.

그런데  이번 주 과제를 진행하면서 갑자기 머리속으로 Application Service와 Domain Service 에 대한 차이 및 역할에 대해
생각하게 되었다.(왜 갑자기 각성한 것인지는 나도 잘 모르겠다.. 계속 생각하고 있어서 그런가..?)

• Application Service
  트랜잭션 관리, 여러 Repository 호출, DTO 변환 등 하나의 유스케이스 흐름을 조율하는 지휘자 역할.
• Domain
  product.decreaseStock()처럼, 외부 기술에 의존하지 않고 자신의 상태와 규칙에만 집중하는 순수한 비즈니스 로직의 집합.

이 원칙을 기준으로 User, Product, Order 등 모든 도메인의 Facade와 Service를 하나의 ApplicationService로 통합했다.
각 계층의 책임을 명확히 정의하는 설계의 영역이라는 것을 어렴풋이 알게 되었다.

---

💭 이런 고민이 있었어요

• 리팩토링 전 내 코드는 Application 계층의 Facade가 Domain 계층의 Service를 그대로 호출만 하는, 사실상 의미 없는 구조였다. 해당 구조를 쓴 이유는 그저 기존에 제공해준 프로젝트 탬플릿의 예시와 다른분들의 프로젝트 구조가 그런 형식이 많았기 때문이다.
  Domain 계층에 있던 Service가 @Transactional을 사용하고, 다른 도메인의 Repository까지 주입받는 등, 실제로는 Application Service의 역할을 하고 있었던 것이다. 역할과 위치가 뒤죽박죽이었던 셈이다.
• 문제를 해결하기 위해 계층별 역할을 명확히 하자는 기준을 가지고 리팩토링을 마음먹고 과감히 둘을 합쳐 xxApplicationService로 통합했다. 역할이 명확해지고 코드가 간결해졌다.
• 하지만 곧 새로운 고민이 생겼다.
  ProductApplicationService처럼 여러 조회 조건과 다른 도메인(Like)과의 연동이 필요한 서비스가 너무 비대해지는 '뚱뚱한 서비스(Fat Service)' 문제가 보이기 시작했다. "결국 문제를 한곳으로 옮기기만 한 건 아닐까?" 하는 생각이 들었다.

---

💡 앞으로 실무에 써먹을 수 있을 것 같은 포인트

• Application Service는 유스케이스의 관문이다.
  외부와의 통신, 트랜잭션, 데이터 조합은 모두 이 계층에서 시작하고 끝내야 한다는 원칙을 세울 수 있게 되었다.
• 도메인은 스스로 일하게 하라.
  Application Service는 도메인 객체에게 "재고 줄여줘(decreaseStock)"라고 명령할 뿐, 재고가 몇 개인지, 줄일 수 있는지 등의 판단은 도메인 객체가 스스로 하도록 위임해야 한다는 것을 배웠다.
• '뚱뚱한 서비스'는 CQRS로 해결할 수 있다.
  서비스가 비대해지는 문제를 마주했을 때, 시간이 없어 존재만 파악하고 적용하지 않았지만
  명령(Command)과 조회(Query)의 책임을 분리하는 CQRS 패턴이라는 구체적인 해결책이 있다는 것을 알게 되었다.
  복잡한 조회 로직을 별도의 QueryService로 분리하면, 기존 서비스는 핵심적인 상태 변경 로직에만 집중할 수 있게 된다.

---

🤔 아쉬웠던 점 & 다음 주에 해보고 싶은 것

• 시간이 된다면 이번에 배운 것을 바탕으로, ProductApplicationService에 CQRS 패턴을 직접 적용해보고 싶다.
  복잡한 searchProducts 조회 로직을 ProductQueryService로 분리하여, '뚱뚱한 서비스' 문제를 실제로 해결해보고
  그 효과를 체감하는 것이 다음 목표다.