Package 구조는 어떤식으로 잡고 계신가요
양완수
[프로젝트 기관 도메인].[프로젝트 이름] 을 상위 Package 로 설정하고
각 서비스되는 단위 별로 하위에 작성하고 그 하위에 dao , service , domain interface/
implement 등을 같은 레벨로 두고 web package 에 controller,form,, 등등을 같은 레벨로 두고 있
습니다.
이유는 서비스 단위로 한눈에 보기 편하라고 이렇게 하고있습니다.
[상위 Package].XX
Book
interface BookService
class GenernalBookService
BookDao
IbatisBoosDao
[상위 Package].XX.web
class BookListController
class BookListForm
class BookVaildator
헌데 이런 구조가 좀 거슬리기 시작한게 여기 저기 중복되는 구조가 발생하기 시작했습니다.
그리고 중복되는 코드들이 작업자들끼리 발생하더군요
예를 들어 XX 서비스에서 사용하기 위한 util 들이 YY 서비스에서도 나타나기 시작하고 이곳저곳 나타나기도 해서요
그래서 spring sample 들을 보다 보니
[상위 Package].dao
[상위 Package].domain
[상위 Package].domain.logic
[상위 Package].service.[service 묶음]
[상위 Package].web
요런 식으로 jpetstore 은 하고 있었습니다.
이런 구조가 가지는 장점은 무얼까요???
그리고 [상위 Package].domain.logic 의 용도는 무엇인지 궁금합니다.
회원여러분들은 Package 구조는 어떤식으로 잡고 계신가요?
이재일
--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.
Sungchul Park
사실 둘이 다른 패키징 방법이라기 보다는 무엇을 우선시 하느냐에 따라 갈리
는 듯 한데요. 양완수님의 회사에서 쓰는 방식은 업무를 우선하는 방식이고
스프링 예제는 계층을 우선하는 방식으로 봐야겠죠. 우선 한다고 표현한 이유
는 일단 각자의 스타일로 패키지를 나누기 시작했다가도 시스템이 복잡해지면
업무 별로 나눈 하부를 또 계층으로 나눠서 패키징 하기도 하고, 반대로 계층
으로 나눈 상태에서 다시 업무로 나누니까요.
전 나중에 분산 배치할 때, 그러니까 물리적으로 여러 서버에 나누는 경우나
OSGI 같은 격리된 모듈 구조로 가거나 할 때 어떻게 패키징할 것인지에 따라
결정하면 된다고 봅니다. 좀 규모가 작고 업무 별로 개발하는 팀이 다르거나
따로 배포한다거나 할 일이 없다면 계층 별로 패키지를 나누는 것이 단순하기
는 합니다.
> 헌데 이런 구조가 좀 거슬리기 시작한게 여기 저기 중복되는 구조가 발생하기 시작했습니다.
> 그리고 중복되는 코드들이 작업자들끼리 발생하더군요
중복된 코드를 공통 컴포넌트로 분리해서 공유하도록 하는 방법을 쓰면 해결
될 듯 합니다. 즉, 지금 업무별로 패키지를 나누셨는데 commons라는 패키지를
하나 더 만드시고 그 안에 하부 패키지를 만들어 이런 저런 공통 컴포넌트를
몰아 넣는 방법이 한 예겠죠.
> 그래서 spring sample 들을 보다 보니
> ....
> 요런 식으로 jpetstore 은 하고 있었습니다.
> 이런 구조가 가지는 장점은 무얼까요???
좀 더 단순한 구조라고 생각합니다. 단순하다는 말은 구조적으로 단순하다는
말이 아니라 기계에 더 가깝다는 의미인데 추상화가 덜 된 패키징 방법이란
뜻으로 말씀 드린 거라고 보시면 됩니다. 그래서 규모가 아주 크지 않다면 이
구조가 편해 보입니다.
> 그리고 [상위 Package].domain.logic 의 용도는 무엇인지 궁금합니다.
>
domain 패키지에는 모델 객체를 담아두고 있고 그 하부 domain.logic 패키지
에는 각종 로직을 담고 있습니다. jpetstore는 아주 단순한 샘플이라서 이런
구조로 해결되지만 조금만 커져도 복잡해집니다. 보통은 domain 패키지 하부
에 업무 별로 하부 패키지를 만들어 모델 객체를 담아 두는 것 같습니다.
> 회원여러분들은 Package 구조는 어떤식으로 잡고 계신가요?
제가 요즘 만드는 애플리케이션의 패키지 구조를 말씀 드리겠습니다.
~.domain
~.domain.업무
~.infra.업무
~.web
~.domain.업무 패키지에는 모델 객체와 Service 인터페이스, Service 구현,
그리고 Dao 인터페이스가 들어갑니다.
~.infra.업무 패키지에는 배포될 환경과 관련된 코드가 들어가는 데 주로
~.domain.업무 패키지에서 정의한 Dao 인터페이스의 구현물이 들어갑니다.
~.web은 생각하시는 것 같이 웹 단의 모델과 컨트롤러가 들어갑니다.
좀 더 복잡해지면 ~.domain에서 서비스를 빼서 ~.service에 담기도 하는데 큰
효과는 없더군요. 만약 OSGi를 쓴다면 이렇게 해보고 싶습니다.
~.컴포넌트
~.컴포넌트.domain
~.컴포넌트.infra
~.web
여기서 컴포넌트는 아마도 업무랑 비슷하겠지만 좀 더 작은 단위가 될 듯 합니다.
밥 삼촌의 객체지향 설계 원칙을 보면 흔히 말하는 SOLID 말고 패키지 설계에
도움이 되는 원칙도 있습니다. 참고하시면 도움이 될 겁니다.
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod