헥사고날 아키텍처에서 신고(Report) 엔티티의 도메인 위치 딜레마

  1. 상황

  비밀로그(BimilLog) 프로젝트를 헥사고날 아키텍처로 설계하면서 신고 기능을 구현하게 되었다. 현재 시스템은 7개의 주요 도메인(admin, auth, comment, notification, paper, post,
  user, common)으로 구성되어 있으며, 각 도메인은 명확한 책임과 경계를 가지고 있다.

  신고 기능의 요구사항은 다음과 같았다:
  - 글 신고: 부적절한 게시글 신고
  - 댓글 신고: 부적절한 댓글 신고
  - 건의사항: 사용자가 시스템에 대한 건의사항 제출
  - 신고 관리: 관리자가 신고 내역을 조회하고 처리

  자연스럽게 각 기능은 관련 도메인에 배치되었다:
  - 신고 하기→ user 도메인의 in 어댑터 (UserCommandController)
  - 신고 조회 → admin 도메인의 쿼리 서비스

 

글, 댓글등은 ENUM을 활용하였다. 글, 댓글의 인어댑터에 별도의 api를 만드는것은 비효율적이기

 

그리고 각 도메인의 결합도를 낮추고 별도 구현체를 만드는 코드중복을 피하기위해 이벤트리스너를 통한 느슨한 결합으로 코드를 만들었다.

 

---

  2. 문제 발생

  구현을 진행하면서 핵심적인 딜레마에 직면했다: Report 엔티티는 어느 도메인에 위치해야 하는가?

  각 선택지마다 명확한 근거가 있었다:

  Admin 도메인:
  - 신고를 조회하고 관리하는 주체가 Admin이다
  - 관리자 기능의 핵심 데이터라 볼 수 있다
  - 현실적으로 신고 처리는 관리자의 몫이다

  User 도메인:
  - 신고를 생성하는 주체가 User이다
  - 건의사항이 이미 User 도메인에 있다
  - 신고자의 관점에서 보면 User 도메인이 자연스럽다

  별도 도메인:
  - Report는 독립적인 비즈니스 개념이다
  - 미래에 복잡한 신고 처리 로직이 필요할 수 있다
  - 도메인 간 의존성을 최소화할 수 있다

---

  3. 고민

  이 문제는 단순한 코드 위치 결정을 넘어서 헥사고날 아키텍처의 핵심 원칙들과 맞닿아 있었다.

  도메인 주도 설계(DDD) 관점에서의 고민:
  - Report는 진정한 도메인 개념인가, 아니면 단순한 데이터 저장소인가?
  - 유비쿼터스 언어에서 "신고"의 주인은 누구인가?
  - 애그리거트 경계를 어떻게 설정해야 하는가?

  헥사고날 아키텍처 원칙과의 충돌:
  - 각 도메인의 독립성을 해치지 않으면서 어떻게 공통 엔티티를 관리할 것인가?
  - 이벤트 기반 통신을 활용할 때 어느 도메인이 이벤트를 발행하고 구독해야 하는가?
  - Common 도메인에 비즈니스 엔티티를 두는 것이 과연 옳은가?

  실용적인 고려사항들:
  - 현재 시스템 규모에서는 과도한 분리가 될 수 있다
  - 하지만 미래 확장성을 고려하면 지금 결정이 중요하다
  - Common 도메인에 비즈니스로직을 두면 안된다. Common의존성이 각 도메인에 침투하게 되고 Common이 쓰레기통화(rubbish bin risk)가 될수도 있다.

 

현재 가장 고려되는건 별도 도메인 분리다 코드량이 많아지는게 문제가아니다 코드량이 많아져도 읽기 쉬운 코드를 만드는것이 중요하다 읽고 이해하기 쉬운 코드는 코드량이 많아져도 체감상 복잡하지않게 느껴진다.