3 câu hỏi đã được viết

0

안녕하세요! ☺ 참 좋은 질문 주셔서 감사합니다. 사실 저는 강의 내에서도 "도메인" 별로 패키지를 나누고 있다고 생각하는 편이에요! 다만 "계층 (~= 역할)" 별로 먼저 패키지를 1차적으로 나눈 후에 도메인 단위로 나눌 뿐이죠. 그리고 저는 지금도 이 방식이 조금 더 낫다고 생각합니다. 다만 이 방식이 절대적으로 낫다기보다 제가 선호한다는 뜻이고, 5.5 : 4.5 정도로 봐주시면 될 것 같아요! ☺

도메인 별로 먼저 나누는건 이렇게 생각해볼 수 있겠죠!

user/
  UserController
  UserService
  UserRepository
book/
  BookController
  ...

유저 안에서 더 나눌 수도 있을거에요! (user -> controller, user -> service 처럼)

계층 별로 나누는 것은 강의에서 처럼

controller/
  user/
    UserController
repository
  book/
    ....

와 같이 계층 -> 도메인 그 후 클래스를 위치시키는 방법인데요!

제가 후자의 방식을 더 선호하는 이유는 1) 멀티 모듈 프로젝트를 구성하다 보면 도메인 단위로 모듈이 구성되는 것 보다 계층 별로 모듈이 구성되는 경우가 더 흔하고 2) 여러 도메인이 조합된 형태의 로직을 구성할 때 조금 더 유연하다고 생각하기 때문에 그렇습니다!

만약 시작부터 (MAU 수백만 이상의) 큰 규모의 시스템을 구상하고 있고 도메인 단위로 MSA 분리를 확실하게 계획하고 있다면, 도메인별로 패키지를 구성하는 것이, 추후 패키지만 분리하면 하나의 micro-service 가 되어 좋은 측면도 있습니다. 🙂

답변이 도움이 되었으면 좋겠습니다. 감사합니다. 🙇

0

안녕하세요, 인프런 AI 인턴입니다. 포기안할게요오님!

패키지 구조에 대한 질문 주셨네요. 패키지를 역할별로 나누는 것과 도메인별로 나누는 것은 각각 장단점이 있습니다.

• 역할별 패키지 구조: 이는 전통적으로 많이 사용하는 구조로, MVC 패턴을 따르며 컨트롤러, 서비스, 리포지토리를 각각의 패키지로 구분하는 방식입니다. 이런 구조는 각 레이어의 역할이 명확하게 분리되어 있어 유지보수할 때 용이합니다.

• 도메인별 패키지 구조: 최근 많이 채택되는 방식으로, 하나의 도메인에 해당하는 모든 클래스 (컨트롤러, 서비스, 리포지토리 등)를 하나의 패키지에 모아두는 방식입니다. 이 방식은 기능 단위로 코드를 분리하여, 각 기능에 관련된 변경 사항을 파악하고 수정하는 데 유리합니다.

어떤 방식이 좋은지는 팀의 개발 스타일이나 프로젝트의 특성에 따라 다를 수 있습니다. 작은 프로젝트에서는 역할별 패키지 구분이 더 직관적일 수 있지만, 대규모 프로젝트에서는 도메인별로 구조화하는 것이 더 깔끔한 관리가 가능할 수도 있습니다.

이 주제와 관련하여 유용한 답변이 있을까 하고 관련 강의를 찾아보니, 30강 질문이라는 질문 글에서도 패키지 관리에 대한 논의가 이루어지고 있습니다. 참고하시면 도움이 될 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.