저도 재성님의 분리방식과 유사하게 사용하고 있습니다. 저의 경우 제가 조합&빌드 한 프레임웍을 randy라 명명하고. 라이브러리성 코들은 randy.core 패키지 하위에 위치시키고

이 프레임웍을 사용해서 프로젝트 진행시 발생하는 애플리케이션 코드들은 고객사의 도메인을 prefix로 하는 패키지를 구성해서 진행하고 있습니다.

말씀하신데로 패키지명으로 명확하게 구분이 되어 참 깔끔하게 사용하고 있답니다.

음 이런 이야기였군 어젠 술취해서 의도를 잘못 파악 했네.... 라이브러리용 코드에 대한 페키지명은 동감 하는데 애플리케이션 코드의 페키지 명은 좀 고민해 볼필요가 있을거 같다. 이부분은 회사의 규모에따라 이야기가 틀려질듯 하다. 작은 규모의 회사라면 프로젝트 명을 페키지로 사용하는건 문제가 없을듯 하지만 대규모의 회사라면 이야기가 다를 것 같다. 1. 전사 소스 관리에서의 문제점. - 전사적인 컨벤션 즉, net.daum.business.project.domain 형식인경우가 많은데 여기서 project.domain형식으로 되면 전사적인 소스 관리 차원에서 본다면 계층구조가 너무 무질서 해질수 있을 듯 하다. 모든 프로젝트 이름이 최상위 페키지로 나와버리면 일년에 수천,수만개의 프로젝트가 진행되는 상황에서 비즈니스별로 그룹하기가 너무 힘들듯 하다. 2. 프로젝트 중복 문제. - 간단한 예를 들어 삼성에서 겔럭시 프로젝트를 예로보면 galaxy라는 프로젝트가 있다고 하자. 이 프로젝트 명은 실제 휴대폰(하드웨어)을 개발하는 곳에서도 사용할것이고 그 휴대폰에 들어가는 소프트웨어를 개발하는 부서에서도 사용하며 해당 product를 판매 하는곳, web service를 하는곳... 여러 곳에서 사용할것이다. 이럴 경우에 galaxy....형식으로 페키지를 써버리면 동일한 package로 시작하면서도 각각의 다른 사업을 바라보는 페키지들이 난무할 가능성이 있을것 같다. (예를 들어 H/W에서 galaxy.user.info[휴대기기 사용자 정보] 랑 web service에서 galaxy.user.info[web login 사용자 정보]랑은 다를것이다.) 그렇기에 회사규모가 어느정도 되는 곳에서는 각 프로젝트 단위를 묶어 줄수있는 부분(보통 업무 또는 팀, 그룹같은)이 필요 할듯 하다. 물론 이런 것이 꼭 정답은 아닐 것 이고 각 상황에 따라 유연하게 사용되어야 겠지만 2,3단계의 package를 줄여서 간단히 depth가 짧아지는 정도의 관리 이점만 있다을 위하여 이렇게 하는것은 아닐것 같다.

결론은 어플리케이션 코드의 페키지 명을 회사도메인.부서..같은 형식으로 하는것은 꼭 외부 공개여부가 중요 문제가 아닌 해당 프로젝트, 서비스의 분류를 더 큰 그룹으로 잡아줘야 하느냐의 판단에 근거 해야할듯하다.

@jhindhal.jhang 나도 회사 규모에 따라, 회사 표준에 따라 달라져야 된다는 것에 공감한다. 이 같은 제안을 한 이유는 프로젝트 상황에 따라 다양한 패키지 구조가 나올 수 있을 것이라 생각하는데 너무 도메인 위주의 package 구조만 고집하는 것은 아닌가라는 의구심이 들어서 글 남겨 봤다. 프로젝트 시작할 때 패키지 구조 잡는 것에도 의문을 가지고 접근해 봤으면 하는 바람으로...