반응형
올 1월에 만들었던 DDD 자료(http://www.slideshare.net/madvirus/ddd-final)의 41 페이지에 대해 박재성 님과 박성철 님이 의견/문의를 주셨다.
- 박재성님 글: http://www.slipp.net/questions/30
- 박성철님 글: https://www.facebook.com/fupfin/posts/499236183440392
필자가 왜 그렇게 구성했는지에 대해 설명하는 게 논의에 도움이 될 것 같아 블로그에 글을 남겨본다.
41 페이지에 있는 내용
예전에 필자가 한 모임에서 발표했었던 DDD 자료를 보면 DDD를 구현할 때 각 레이어의 요소를 아래와 같이 정리했었다. (아래 그림에서 DomainApplicationService는 클래스입니다. 인터페이스라고 잘못 표기되어 있습니다.)
의견/취향
다음과 같은 의견/취향 때문에 DataLoadingService를 ApplicationService와 분리하고, 또 DataLoadingService를 ui 레이어에 위치시키게 되었다. (의견과 취향을 구분했다.)
- (의견) UI에서 필요로 하는 데이터가 도메인 객체가 제공하는 데이터와 일치하지 않는다면, 도메인 객체가 아닌 UI에서 필요로 하는 데이터를 제공하는 것이 좋다고 판단하며, 이를 위해 도메인 객체를 UI 특화된 데이터로 변환하는 기능이 필요하다.
- 이 변환 기능은 어플리케이션이나 도메인 레이어에 속하기보다는 ui에 특화된 기능이다.
- 따라서, 도메인 객체를 UI 객체로 변환하는 역할은 ui 레이어에 위치해야 한다.
- (의견) 도메인 엔티티가 데이터 구조가 아니라 기능 중심의 객체라면, 객체 자체를 ui 노출하기 보다는 ui에서 필요한 데이터만 추려서 제공하는 것이 좋다고 생각한다.
- 이렇게 함으로써 UI 영역에서 객체를 실행하는 것을 막을 수 있다.
- (취향) 물론, 도메인 객체의 상위 인터페이스를 제공함으로써 UI 영역에서 객체 실행을 어느 정도 방지할 수 있지만, JSP/Velocity 등 리플렉션을 사용하는 곳에서 실행할 수 있기 때문에, 인터페이스 사용보단 별도 DTO를 사용하는 것을 선호한다.
- (취향) OSIV(Open Session In View)를 좋아하지 않는다. 트랜잭션 범위에 렌더링(JSP 렌더링, XML 변환 등)이 포함되는 걸 선호하지 않는다. OSIV는 어떤 면에서 클라이언트에서 트랜잭션을 제어하는 것처럼 느껴지기도 한다.
- 이런 이유로, ORM을 사용할 경우, 렌더링에 필요한 모든 데이터가 로딩된 상태로 렌더링 영역에 전달되는 것을 선호한다.
만약 아래와 같은 경우라면, DTO 변환 없이 ui 레이어에서 리포지토리에 접근해서 도메인 엔티티를 직접 사용해도 된다는 것이 개인 의견이다.
- 도메인 엔티티가 기능이 거의 없는 단순 데이터 구조이다.
- 즉, get/set 메서드 또는 public 필드를 가진 인스턴스이다.
- 예를 들어, 게시글/첨부파일/방명록과 같이 특별한 기능을 갖지 않고 데이터 구조에 가까운 것들
- 데이터 구조인 도메인 엔티티와 화면이 거의 1대 1이다.
------- 2011-11-20 내용 추가
이일민님의 의견 및 저의 고민에 대한 답글: https://plus.google.com/