분리된 일반 리포지토리 네이밍에 대한 질문입니다.

Question

안녕하세요~ 김영한 강사님. 기본편 부터 쭉 들으며 열정넘치신 강의 덕분에 많은 배움이 있었습니다. 강의 중에 리포지토리 네이밍에 관해 궁금한것이 생겼는데요, 메인 리포지토리 분리할 경우 고려할 사항에 대해 말씀해주셨는데요, 다음과 같이 정리해 보았습니다. * - Command( 명령성 ) / Query( 복잡한쿼리 ) * - CoreBusinessLogic( 핵심비지니스로직 ) / ViewPrivateLogic(View 계층쿼리로직 ) * - LifecycleStepedLogic( 생성주기에 따른 절차적로직 ) 알려주신 QueryRepository 외에 분리되야 할 부분의 리포지토리의 이름들을 어떻게 구분하면될까요? Query : query.XxxQueryRepository Command : command.XxxCommandRepository CoreBussiness : ? LifecycleStepedLogic : ?? 추측해본 결과로는 이런방식인데요, 1. 실무서 이런방식으로 구분하시는지, 2. 강의 내용 외 분리시킬 리포지토리의 패키지와, 이름을 각각 어떤이름으로 사용하시는지 3. 묶어서 사용할 경우, 어떤것들 끼리 묶어서 사용하시는지 간략한 구체적인 사례들이 궁금합니다. 읽어주셔서 감사합니다!

김영한 · Answer

안녕하세요. Truestar님 결론부터 말씀드리면, 정답이 없고, 규모와 상황에 따라서 너무 많이 다릅니다. 처음부터 이렇게 query와 command 같은 식으로 쪼개는 것은 응집성 차원에서 좋은 설계는 아닙니다. 그런데 규모가 너무 커지면 관리를 위해서 이렇게 쪼개는 것도 좋은데, 그것은 경험치가 필요합니다. 그래서 항상 단순한 구조를 유지하고, 필요에 의해서 구분을 해야합니다. 예를 들어서 회원, 주문 도메인과 웹 컨트롤러가 있을 때 가장 단순한 패키지 구조는 다음과 같습니다. 1. 단순히 계층을 짜르는 구조 web - member - order serivce - member - order repository - member - order entity - member - order 2. 도메인 중심으로 진행하는 구조 member - web - service - repository - entity order - web - service - repository - entity 2번처럼 깔끔하게 떨어지면 좋겠지만 사실 그런 경우는 거의 없습니다. 생각해보면 화면 하나에서 주문도 필요하고 회원도 필요한 경우가 너무 많습니다. 그래서 web은 화면 단위로 만들고, 뒤에 서비스 계층 부터 재사용성 가능하게 설계하는 방법입니다. 3. web은 화면별로, 나머지는 도메인 별로 web - 화면별로 각각 컨트롤러 생성 member - service - repository - entity order - service - repository - entity 이제부터는 여기에서 프로젝트 상황에 따라 응용입니다. 상황이나 복잡도에 따라서 계층을 더 둘 수 있고, 줄일 수 있습니다. 그리고 주문 도메인이 너무 복잡하면 주문쪽의 리포지토리를 command, query로 쪼개도 되구요^^ 핵심은 패키지에 대해서 유연한 사고를 가지고, 패키지 의존관계를 최대한 단방향으로 단순하게 풀어가는 것이 중요합니다. 도움이 되셨길 바래요.

Truestar · Answer

우문현답 을 주셨네용..프로젝트에 적용해보겠습니다. 넘나 감사드리와용!! 쵝오입니다!