여러 도메인을 엮는 코드는 어디에 둘까

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

하나의 기능이 여러 도메인을 가로지르는 일은 흔하다. 게시글을 삭제하려면 게시글뿐 아니라 현재 사용자와 권한 검증도 필요할 수 있다. 그렇다고 여러 개념이 등장한다는 이유만으로 중립적인 공통 패키지를 만들면 결정이 해결되기보다 가려질 때가 많다.

먼저 주된 행위와 보조 규칙을 나눈다. 지금 하려는 일은 게시글 삭제이고, 권한 검증은 그 삭제를 가능하게 하는 조건이다. 다음 질문은 검증 규칙의 주인이 어느 도메인인가이다.

규칙의 이름부터 분명히 한다

서비스 전체의 일반 사용자를 검증하는 기능이라면 사용자 도메인에 속할 가능성이 높다. 반대로 ‘리뷰 사용자’처럼 리뷰 안에서만 의미가 있는 개념이라면 리뷰 쪽에 두는 편이 자연스럽다. 이름을 정확히 붙이면 개념이 전체에 걸친 것인지 특정 영역 안에만 존재하는지 드러난다.

따라서 실제 비즈니스 모델이 패키지 규칙보다 먼저다. 짧은 설명만으로는 조건부 판단만 할 수 있다. 질문 속 사용자가 서비스의 일반 사용자라면 사용자 검증을 리뷰나 게시글 아래에 두는 순간 소유권이 실제보다 좁아 보인다. 리뷰에서만 존재하는 사용자라면 반대 결론이 맞을 수 있다.

여러 도메인을 조율하는 클래스는 주된 행위가 있는 쪽에 둘 수 있다. 예를 들어 리뷰 추가 클래스가 리뷰 저장소와 사용자 검증기를 생성자에서 받는 구조라면, 리뷰 추가가 중심이고 다른 도메인의 규칙이 필수 조건이라는 사실이 코드에 드러난다.

임포트로 관계를 확인한다

임포트는 단순한 컴파일러 잡음이 아니다. 비즈니스 클래스에서 펼쳐 보면 어떤 주변 도메인이 필요한지 보여준다. 리뷰 작업이 사용자와 제공자 개념을 임포트한다면 그 협업 관계가 눈에 보인다. 모든 임포트를 막연한 공통 패키지 뒤에 숨기면 이 신호를 잃을 수 있다.

위치가 애매할 때는 작은 실험을 해볼 수 있다.

1. 소유권이 있다고 생각되는 패키지로 클래스를 옮긴다.
2. IDE가 임포트를 갱신하게 둔다.
3. 어떤 클래스와 레이어가 영향을 받는지 살핀다.

바뀐 파일은 그 클래스의 실제 영향 범위를 보여준다. 비즈니스 코드와 하위 구현체가 동시에 영향을 받는다면 레이어 경계를 어색하게 가로지르는 것은 아닌지 확인해야 한다. 한 무리의 구현 클래스만 바뀐다면 도메인 개념보다 구현 보조 객체일 가능성이 있다. 패키지 이동은 결합도를 구체적으로 보는 값싼 실험이다.

생성자 의존성도 단서가 된다. 객체가 존재하려면 늘 필요한 협력자인지, 한 번의 호출에서만 넘어오는 값인지 구분할 수 있다. 하나의 단서로 결론을 내릴 수는 없지만 팀이 근거를 놓고 대화하는 데 충분히 쓸 만하다.

모양보다 응집을 본다

마지막 기준은 응집이다. 같은 비즈니스 이유로 함께 바뀌는 개념을 모았는가? 긴 설명 없이도 패키지 위치가 역할을 보여주는가? 의존 방향이 소유권을 따르는가?

게시글 삭제 사례라면 삭제 흐름은 게시글이나 리뷰 작업 쪽에 두고, 일반 사용자 권한 검증은 사용자 도메인에 두는 편을 먼저 생각한다. 호출하는 쪽이 지금 게시글이라고 해서 사용자 규칙까지 게시글 아래로 옮기지는 않는다.

다른 비즈니스에서는 답이 달라질 수 있다. 권한 정책 자체가 충분히 커졌다면 별도 권한 도메인이 생길 수도 있다. 목표는 어디서나 통하는 패키지 트리가 아니다. 코드의 실제 의존 그래프를 근거로 각 개념이 무엇을 소유하는지 팀이 함께 설명할 수 있는 상태다.