Rich Domain Model

2008/01/28 17:03

먹기엔 덜익은 DDD 와 Rich Domain Model

Rich Domain Model를 구현 하다가 생각을 정리해 본다.

현재 일반적인(이상적인) J2EE 개발 아키텍처는 3Tier로 구성되는 경우가 많다. 이미 잘 알고 있는것처럼 위에서부터 Presentation Layer,Business Layer,Persistence Layer 이다. 여기서 주 관심사는 역시 Business Layer인데 이는 모든 프로젝트가 이 Layer의 완성도에 따라 품질이 좌우되기 때문이다.(UI를 더 중요시 하는곳도 있지만) 그래서 개발자들 사이에 주요 이슈가 되는 사항이 Business Layer의 구성에 있다.

현재 내가 알고 있는 일반적인 구성을 보면, Business Layer의 주 객체는 Domain Model이다. 도메인모델은 비지니스의 로직이 처리되는데 거의 필수적으로 있어야 하는 VO(Value Object)로 쓰인다. 즉 여기서 도메인 모델은 VO의 의미 정도로 아주 작은(작지만 광범위한) 역할에 불과하다. 그리고 이놈은 3Tier 전방위적으로 사용되고 있다. 모든계층의 VO로써 사용되고 있는 것이다. VO는 그런 용도로써의 본 아키텍처에서 아주 훌륭히 자기 역할을 다 하고 있다.

최근 관심사에 Rich Domain 바람이 불어서 DDD(Domain Driven Design - 여기서 DDD는 개발자관점에서만 이야기 한다.)가 서서히 표면 위로 올라 오고 있다. 이놈들의 핵심은 도메인이다. 진정한 OOP를 꿈꾸며 도메인 객체를 좀더 OO답게 풍푸한 기능을 넣자는 얘기다. 과거부터 왜 이런 시도를 안했겠는가. 노력을 했지만, 아마도 J2EE 환경에서 여러가지 인프라가 그런 OOP를 제한 했을거라는 것을 쉽게 예상할수 있다. 그런데 이제는 J2EE에서 그런 Rich Domain Model이 가능하단 말인가?.

가능하다.
실은 개념 자체는 오래전에 나왔과 최근엔 여러가지 기반기술들이 알려지면서(내가 알게 됨으로써 알려진) 이런것이 가능해 졌다. 그런 기술들은 대략 나열해보면 이렇다. AOP(AspectJ), ORM, SpringFramework, POJOs 인기, 의지 등이다. 최근에 알려진(알려졌지만, 공개되지는 않은) ROOAF(Aplication Framework)도 Rich Domain Model를 기반으로 DDD에 접근한 실사례 중 하나이다. 그런데 ROO('루~'라고 읽는다.) 그게 정말 성공적인 프로젝트 였을까? 라는 의문이 든다. 

최근 나는 Rich Domain Model 기준으로 SI프로젝트 기본 Template를 만들어 볼려고 시도 했었다.
그러나 만만치 않은 복병들이 곳곳에 있어 실제 그것으로 프로젝트를 진행하는것은 거의 죽음에 가깝다는걸 알게 되었다. (적어도 현재까지 나의 수준에서는 말이다.) 왜 그런 결론을 내었을까? 한번 따져 보자.

예를 들어 보자
Member라는 도메인을 만들때 기존 모델 방법과 리치 도메인 모델 방법을 비교해 보자.
기존 방법은 Member가 DAO->Biz->Controller->UI까지 모두 VO로써 역할을 해왔다.
크게 무리없이 잘 돌아가는 아키텍처이다. 좋다 훌륭하다.

리치 도메인 모델에서는 어떤지 보자.
이놈은 Member라는 도메인에 행위까지 들어가 있어서 이 객체를 생성하는데 기존보다 비용이 많이 발생한다. 즉, 함부로 이놈을 생성하는건 비효율적이다는 것이다. 특히 UI에서 이 도메인 객체를 썼다가는 각종 템플릿과 스크립트 언어로 이 도메인 객체를 자주 Call 할수 있다. 이 비싼놈을 말이다. 따라서 이놈을 UI에서는 사용을 자제시켜야 한다. 행위까지 꼭 필요할때 호출해야 한다. 이것을 해결하기 위해 ROO에서는 별도의 Domain Layer를 두고 Presentation Layer에서 직접 호출하지 못하게DO를 격리 시켜버렸다. 대신에 DTO를 상위 Layer에서 쓰게 하였다. ROO의 발상은 좋았다. 그러나 DO와 DTO간의 매핑을 위해서는 기존보다 복잡해질수 밖에없다. 그것을 CG(Code Generation)를 통해서 해결했다고는 하지만 역대 CG가 만족스럽게 잘 돌아가던게 있었던가.

'어디서 읽었는지 기억나지 않지만 코드 자동 생성 기능은 실제 프로젝트 생산성에 아주아주 적은 부분만 차지 한다고 한다.
그래서 코드 자동화에 시간을 많이 투자하지 말라고...(최근 내가 CG 관련 이클립스 플러그인 툴은 테스트하느라 시간을 잡아 먹었다.-_-; )'

어쨌든 확인하지 못한것에 대해서 말하는건 아둔하고, ROO가 성공적이였다니 좋다.(실은 내실력이 안되어 꼬장 부리는것인지도) 단순히 두 도메인 모델 방법으로만 봤을때 Rich Domain Model은 확실히 기존 모델 방식보다 많은 손(DTO)이 간다는건 사실이다. 바로 그것이 문제다. 실은 POJOs를 외치는것도 다 보다 깨끗하고, 가벼운 자바객체를 지향하기 위해서인데 결국은 값비싼 DO 때문에 DTO를 만들어 내야만 하는것이다. 정말로 DDD를 실현하기 위해서는 기존 방법보다 간단 명료해야 하며, DTO 같은 부가적인 객체가 새로 생성되는것이 없어야 한다. 물론 DDD를 실현하기 위해서 모두가 DTO가 있어야 한다고 하는것은 아니다. 상당수는 DTO가 없어야 한다고 생각하는 사람들도 많다. 그러나 아직 그들이 내놓은(내가 알지못하는 것일수도 있고) 것이 없다.

위에서 J2EE 환경에서 Rich Domain Model는 가능하다라고 말했다. 그러나 '가능하다'이지 '실용적이다' 또는 '효과적이다'라는건 아니다. 지금에야 나는 왜 사람들이 DDD를 지향하는 사람들을 보고 빌리버(Believer)라고 하는지 이해가 된다. 그들은 가능하다고 생각하는건 효과적으로 만들수도 있다고 믿는다는 뜻일것이다. 어쨌든 보다 OO스럽다는건 이상적인 프로그래밍에 가깝고, 쉽게 이해를 할수 있게 해준다고 믿기 때문이다.

상상해 보자.
우리의 영리한 CEO 께서는 개발자의 지적인 호기심을 채우라고 놔두지 않는다. 손익계산이 빠른 사장님들은 기존방법보다 시간이 더 걸리지만, 기술적으로는 훌륭하다 라는것을 추켜세워줄 사장은 없다. 따라서 새로운 기술의 방향은 기존 방법보다 더 효율적이라는것을 눈으로 보여줘야 한다. 즉 생산성을 높여줄수 있는 근거를 보여줘야 한다. 여기엔 이번 이야기꺼리(DDD)도 예외일수 없다. 
개발자로써 이 기술은 관심을 가질수 밖에 없지만 앞으로 어떻게 발전되어가는지 지속적으로 주시해볼 필요는 느낀다.(나중에 생산성까지 높여주는 AF가 나올수 있으니 말이다.) 
- 지금 먹기엔 아직 떨뜨름한 감 처럼 느껴진다.-

출처 - http://yunsunghan.tistory.com/123

---

발생일: 2009.09.22

문제:
현재 담당하고 있는 시스템은 스트럿츠로 구현되어 있다.
다른 일반 자바 엔터프라이즈 시스템처럼,
프리젠테이션 레이어 - 서비스 레이어 - 데이터액세스 레이어의 3-tier 구조다.
그리고 그 가운데 데이터 전달을 위한 도메인 객체가 있다.

처음 프로젝트를 할 때에는 이게 표준이구나 싶어서 별 생각없이 구현했는데,
어느 날 문득 궁금해졌다.

왜 도메인 객체들을 단순 VO로만 사용하는 걸까...?
좀 더 객체지향적으로 도메인 객체를 활용하면 좋지 않을까...?

해결책:
위와 같이 단순한 데이터 값의 저장을 위한 VO 역할만 하는 도메인 객체를 anemic domain 이라고 한다.

anemic domain model의 한계를 느끼고 나타난 것이
도메인 객체에 직접 도메인과 관련된 비지니스 로직을 포함하는 도메인 모델이다.
이를 rich domain model 또는 smart domain model 이라 한다. (이게 원래의 java object의 형태 아닐까?)

그리고 이런 rich domain model을 가지고 시스템을 설계하는 것을 DDD(Domain Driven Design)이라고 한다.
스프링프레임웍의 POJO 와 DI 개념이 나오면서 이슈가 되기 시작했다고 한다.

DDD의 장점을 잘 정리해놓은 마소 기사가 있다. 스프링프레임웍과 DDD(pdf)를 참고해보자.

그리고 DDD 사용에 대해 주의점을 알려주는 먹기엔 덜익은 DDD와 Rich Domain Model 포스트도 읽어보자.

출처 - http://ohgyun.com/187