저는 1안으로 개발을 해놨다가 패키지가 많아지면서 코드쫓기에 불편함을 느끼게 되었습니다. (모듈이 늘어나면 늘어날수록 마우스 드래그가 빈번해지고 작업시간이 많아지면 점차 눈의 피로와 함께 저 패키지들 쫓기가 여간 귀찮은게 아니어서요... 패키지들 막 열려있고 view code들 왔다갔다하면 집중도 흐려지구요 ㅠ) 그래서 2안으로 패키징작업을 했습니다. ㅎㅎ;;; 다른 이유보다도 그냥 저 편하자고.... -_-;;;

좀 이상한 코딩인지는 모르겠으나 특정 모듈에서 전 layer를 다 거치는 enum 클래스와 Service layer에서 생성되어 view layer로 전달되는 data set object(?)를 여럿 만들었는데 이를 2안으로 패키징후에 작업하니 코드관리하기가 편리하였습니다. (net.slipp.modulename.enumPack / net.slipp.modulename.Service.DataObj) 이렇게 작업을 해놨는데 맞을까요 ㅎㅎ;;;)

여기서 질문을 드리자면 1안으로 패키지작업시 모듈에 종속되는 Enum 클래스를 만들때에 어떤 패키지에 넣어주어야하며(Enum 클래스를 만드는 것도 맞는걸까요?), Service layer에서 Model 로부터 넘어온 data 가공에 필요한 data set 을 위한 object 를 만드는 일이 옳을까요?

예전에도 한참 고민하던 적이 있었는데, 특별한 정답은 없다는 결론을 내리고는 잊어 버리고 있었습니다. 마침, 이 글을 읽고 며칠간 머릿속에 두고 곰곰히 생각해 봤습니다. 자연적인 형태의 것들을 트리로 옮겨야만 할 때, 가장 중요한 것이 무엇일까 생각해 보았습니다. 보통 모듈화의 편의성 때문에 2안을 따랐지만, 1안도 적극적으로 시도해 보려고 합니다. 좋은 글 감사합니다.

@김문수 enum 클래스야 필요한 경우 종종 만들어서 사용한다. 일반적으로 domain(또는 model 이라고 해야 하나)에서 관리한다. 내가 생각하는 enum과 정확하게 일치하는지는 이후에 소스 코드를 봐야지 알겠는데. enum을 사용하는 경우는 많지 않아서... 그리고 일반적으로 패키지에는 대문자를 사용하지 않는다.

Service layer의 DataObject는 우리들이 일반적으로 이야기하는 Data Transfer Object라는 생각이 드는데 맞는 것인가? 이와 관련해서는 의견이 분분한데 상황에 따라 필요할 수도 있고, 그렇지 않을 수도 있을 듯 하다. 뭐 반드시 만들어야 될 이유는 없을 듯하다. 모든 것이 상황에 따라 필요하고 필요하지 않을 수 있기 때문에..

추후에 소스 코드 함 보여주라. 그럼 더 많은 이야기 나눌 수 있을 듯하다.

@최정열 상황에 따라 2안을 선택할 수도 있다고 생각합니다. 하지만 1안에 대해서도 고민해 볼 필요는 있다고 생각합니다. 이는 프로젝트가 현재 구조로 그대로 유지한다면 모르겠지만 추후 여러 개의 모듈로 분리될 때 이슈가 된다고 생각합니다.

예를 들어 모듈을 분리할 때 layer 별로 분리하는 경우라면 1안이 더 유리하겠죠. 만약 모듈별로 분리된다면 2안이 더 유리할 것으로 생각됩니다. 하지만 모듈을 분리할 때 각 패키지간에 cyclic dependency가 없는 상태라야 분리가 용이할 것입니다. 그런 관점에서 볼 때 cyclic dependency가 발생할 가능성이 적은 1안이 미래의 변경 가능성에 더 쉽게 대응할 수 있지 않을까 생각합니다.

설계가 잘되어 있고, 모듈 활용에 대한 강력한 통제 이루어지고,

개발자들이 잘 따라오는 프로젝트 라면 1안이 좋을 것 같습니다.

하지만 개발자(또는 업체)가 자주 바뀌고 교육도 잘 안되거나 규모가 커져서

컨트롤이 힘들어지는 프로젝트라면 차라리 2안으로 가는게 더 나을 것같습니다.

오랜만에 package 구조 관련해 관련 내용을 찾다보니 Package by feature, not layer가 눈에 띈다.

최근에 MSA(micro service architecture)에 대한 논의도 많이 되고, 각 기능별로 응집력을 높인다는 차원에서는 이 문서와 같이 기능 단위로 나누는 것이 좋겠다는 생각이 든다.

저도 예전에 자바지기님과 같은 고민을 한적이 있었습니다. 혼자하는 프로젝트도 그렇고 여럿이 하는 프로젝트도 그렇고 기능단위 패키지 분리가 개발 피로도를 비약적으로 낮춰주기 때문에 선호합니다.