여러 엔티티와 관계를 갖는 엔티티의 패키지

Question

패키지 구조에 관해 고민이 있습니다.현재 진행하고 있는 프로젝트에서는 대략적으로 아래처럼 도메인형 패키지 구조를 사용하고 있습니다.com.example ├ domain │ ├ user (사용자) │ │ ├ controller │ │ ├ service │ │ ├ repository │ │ ├ dto │ │ └ entity │ └ trade (거래 게시글) │ ├ controller │ ├ service │ └ dto └ global ├ config ├ error └ util여기에 지역을 나타내는 엔티티를 추가하려고 합니다.구현하려는 기능은 사용자가 사는 지역과 거래 게시글에 설정된 지역이 같아야 거래할 수 있는 기능입니다.그래서 사용자 엔티티와 거래 게시글 엔티티 내에 지역 엔티티를 넣어야 하는데이 지역 엔티티를 어느 패키지에 넣어야 할지 고민입니다.domain 패키지에 새로운 area.entity 패키지를 만들지,global 패키지에 common.entity 패키지를 만들지,아니면 다른 방법을 써야 할지 고민입니다.현업에서 사용하는 방법이나 다른 좋은 방법이 있다면 알려주세요.

wharup · Accepted Answer

domain 패키지에 area.entity 패키지를 만드는 게 자연스럽겠네요. 지역도 해당 비즈니스의 도메인 로직이 많을 거라 도메인 밑에 배치되는 게 적절하고, 도메인 간에 서로 참조하는 건 일정 부분 발생하기 마련입니다. 도메인 객체가 많아지면 더 상위의 카테고리에 둘 수도 있겠지만.. 지금으로선 불필요해보입니다. 혹시 그 외에 따로 global로 빼야할 것 같은 이유가 있을까요?

DaSA · Answer

entity의 본질은 DB 테이블과 매핑되는 객체임을 한번 더 생각해보면 도움이 될 것 같습니다.프로젝트에 따라 달라지겠지만 여러 도메인이 여러 엔티티를 사용할수도 있고 하나의 엔티티를 여러 도메인에서도 사용할 수도 있어서 도메인 안에 엔티티라던가 엔티티안에 도메인이라던가의 접근방식은 한계가 있다고 생각합니다. 엔티티 객체와 도메인 객체를 나눠서 생각해보시죠~ 엔티티가 곧 도메인 객체인 경우가 아니라면 굳이 특정 도메인 디렉토리 안에 엔티티를 넣어야 할 필요는 없다고 생각합니다.

여러 엔티티와 관계를 갖는 엔티티의 패키지

2개의 답변

Q&A 목록