DDD(Domain Driven Design)에 대한 지식이 많지 않은 개발자들에게 DDD를 이해하고 더 나아가 DDD 기반의 애플리케이션을 만드는 것은 무척 어려운 일이다. 역시 개발자는 코드가 있어야 여러모로 이해가 쉬운 법이다. 여기에서는 DDD 기반으로 소스코드를 생성해 주는 Sculptor를 이용하여 막연하기만 하던 DDD의 개념과 활용법에 대해 좀 더 구체적으로 알아보자.
필자가 DDD라는 용어를 처음 접한 때는 작년 이 즈음으로 기억한다. 스프링 프레임워크를 주제로 하는 강의에서 처음 DDD라는 용어를 접하고 강한 호기심을 가지던 중 사내에 뜻을 같이 하는 개발자들과 스터디를 진행하게 되었다. DDD에 대한 아무런 지식도 없는 상태에서 시작한 스터디였다.
하지만 스터디를 같이 한 개발자들의 적극적인 동참으로 재미있게 진행할 수 있었고, DDD 기반으로 애플리케이션을 개발하고 싶은 욕심까지 생겼다. 그러나 DDD에 대한 이론적인 기반은 에릭 이반(Eric Evans)에 정립된 상태였지만 참고할만한 샘플 애플리케이션이 없었던 탓에 실무에 바로 적용하기에는 무리가 있었다.
실무에 직접 적용하기에는 이론적인 기반도 부족한 상태였고, 샘플 애플리케이션도 없는 상태였기 때문에 DDD에 대한 공부를 잠시 뒤로 미루었다. 그러던 중 TSS(www.theserverside.com) 커뮤니티에 DDD에 대한 필자의 호기심을 자극하는 아티클이 올라왔다. DDD 기반의 소스 생성 툴이라니!
아직까지 제대로 된 샘플 애플리케이션도 없는 상태에서 벌써 소스 생성 툴을 만들었다니 단지 놀라울 따름이었다.
TSS의 아티클에서 다루고 있었던 소스 생성 툴이 바로 이 문서에서 다루게 될 Sculptor이다. Sculptor에서 생성되는 DDD 기반의 예제 소스는 DDD를 시작하는 자바 개발자들에게 많은 도움을 줄 것이다. Sculptor 소스 생성 툴을 통하여 DDD를 시작하는 발판으로 삼았으면 좋겠다.
Sculptor란?
Sculptor는 DDD 기반의 소스 생성을 지원하는 소스 생성 툴이다. DDD 기반으로 애플리케이션을 개발하기 위하여 자바 진영에서 많이 사용하는 프레임워크는 스프링과 하이버네이트 프레임워크이다. 그러나 이들 프레임워크 기반으로 애플리케이션을 개발할 경우 각각의 프레임워크에 대한 기술적인 이해부터 많은 자바 소스, 설정 파일들을 구현해야 한다.
결과적으로 비즈니스 도메인(Domain)에 대한 이해보다는 기술적인 부분에 초점을 맞추게 된다. 그러나 Sculptor를 사용하면 구현해야 할 모든 소스를 자동적으로 생성할 수 있기 때문에 기술적인 부분 보다는 비즈니스 도메인에 집중하는 것이 가능하다.
Sculptor는 비즈니스 도메인을 구현하는데 Domain Specific Language(이하 DSL)를 이용하고 있다. DSL에 대한 파싱은 openArchitectureWare(http://www.eclipse.org/gmt/oaw/, 이하 oAW)를 사용한다.
DSL로 구현된 비즈니스 도메인은 oAW를 이용하여 파싱한 다음 스프링 프레임워크와 하이버네이트 프레임워크 기반으로 소스 코드와 설정 파일을 생성하게 된다. Sculptor가 소스 코드를 생성하는 흐름 및 Sculptor 기반으로 애플리케이션을 개발할 경우의 개발 흐름을 살펴보면 <그림 1>과 같다.
Sculptor를 사용하기 위해서는 비즈니스 도메인을 DSL로 구현하는 것이다. Sculptor는 Maven 빌드 툴을 이용하여 DSL을 파싱한 후에 DDD 기반의 자바 소스와 설정 파일을 생성한다. 개발자들은 Sculptor가 생성한 자바 소스 코드 기반 위에 추가적인 구현 부분을 구현하게 된다. 이 같은 반복적인 과정을 통하여 DDD 기반의 애플리케이션 개발을 완성하는 것이 가능하다.
Sculptor설치 및 소스 코드 생성하기
Sculptor를 설치하는 과정은 Sculptor 사이트에 상세하게 설명되어 있다. Sculptor를 사용하기 위해서는 Maven 빌드 툴이 설치되어 있어야 하며, Maven 빌드 툴에 대한 기본적인 이해가 필요하다.
Sculptor 설치에 대한 자세한 정보는 Sculptor Installation Guide(http://fornax-platform.org/cp/display/fornax/2.+Installation+Guide+%28CSC%29) 문서를 참고하기 바란다. 여기에서는 필자가 Sculptor를 사용할 때 문제가 발생한 부분에 대한 해결 방법만을 다루도록 한다.
Sculptor Installation Guide 문서를 이용하여 설치할 때 부딪히는 첫 번째 문제는 Remote Repository에 fornax Repository가 추가되지 않아서 관련된 jar 파일을 가져오지 못하는 문제이다. 이에 대한 해결책은 빌드 한 프로젝트의 pom.xml 파일의
<리스트 1>은 Maven 빌드 툴이 빌드할 때 fornax Repository를 참조할 수 있도록 추가하는 것이다.
두 번째 부딪히는 문제는 빌드 프로젝트 src/main/resources/templates/SpecialCases.xpt 파일의 인코딩이 맞지 않아 발생하는 문제이다. 이 문제를 해결하기 위해서는 Sculptor Developer Guide(http://fornax-platform.org/cp/display/fornax/7.+Developer%27s+Guide+%28CSC%29) 문서의 SpecialCases.xpt 파일의 본문을 복사한 다음 Western European 인코딩으로 파일을 저장하여 글씨가 깨지지 않도록 해야 한다.
이 문서를 통하여 Sculptor에 의하여 생성되는 기본적인 소스 코드의 구조를 파악할 수 있다. 그러나 개발자들이 직접 소스 코드를 생성해보고 생성된 소스 코드를 분석하며 실행해보는 것이 가장 좋은 공부 방법이라고 생각한다.
Maven 빌드 툴이 익숙하지 않은 개발자들은 다소 어려울 수 있지만 반드시 소스 코드를 생성한 다음 생성된 예제 소스를 실행해 보길 바란다.
Sculptor에 의하여 생성된 소스 분석
Sculptor에 의하여 생성되는 소스 코드를 분석하기 위하여 Sculptor에서 예제로 사용하는 가장 간단한 HelloWorld 예제를 이용해보자. 비즈니스 도메인이 너무 복잡할 경우 소스 코드에 대한 분석보다는 비즈니스 도메인을 분석하는데 너무 많은 시간이 소요되기 때문이다.
이 문서에서는 비즈니스 도메인에 대한 이해보다는 Sculptor에 의하여 생성되는 소스를 분석하면서 DDD에 대하여 더 깊이 이해하는데 그 목적이 있다.
DDD 기반으로 분석한 비즈니스 도메인은 Module, Service, Entity, Repository, Factory, Value Object, Aggregate 등으로 구성되어 있다. 이와 같이 분석한 각각의 구성요소는 DSL을 이용하여 <리스트 2>와 같이 구현하는 것이 가능하다.
DDD 기반으로 분석한 HelloWorld 예제가 <리스트 2>에 그대로 구현되어 있는 것을 확인할 수 있다. <리스트 2>와 같이 구현하는 것이 가능함으로써 개발자들은 HelloWorld 예제의 구현에 대하여 고민하는 것이 아니라 비즈니스 도메인에 대해서 집중할 수 있다. 만약 비즈니스 도메인이 바뀐다면 <리스트 2>를 수정한 후에 다시 빌드만 하면 수정사항이 반영된다.
<리스트 2>와 같이 구현되어 있는 DSL을 Sculptor 툴을 이용하여 소스를 생성할 경우 <그림 2>와 같은 자바 소스와 설정파일이 생성된다.
간단한 HelloWorld 예제임에도 불구하고 <그림 2>와 같이 많은 파일들이 생성된다. 이처럼 많은 파일들이 생성되는 이유는 DDD 자체가 하나의 모듈을 개발하기 위하여 많은 구성요소들을 포함하는 것도 원인이 될 수 있다.
그러나 근본적인 원인은 Sculptor 툴에 있다. Sculptor 툴은 Sculptor 툴에 의하여 자동적으로 생성되는 소스와 개발자들이 수정할 수 있는 소스들을 분리하여 관리할 수 있도록 지원해야 하기 때문에 모든 소스들을 이원화하고 있다. 이 같은 이유 때문에 하나의 모듈을 구현하기 위하여 필요한 소스의 두 배가 넘는 소스가 생성된다.
<그림 3>을 보면 Sculptor 툴에 의하여 자동적으로 생성되는 소스와 개발자에 의하여 수정할 수 있는 소스를 어떻게 이원화하여 관리하고 있는지를 확인할 수 있다.
<그림 3>을 보면 <리스트 2>의 DSL에서 구현한 Service, Entity, Repository 구성요소에 대한 Base 클래스를 가지는 것을 알 수 있다. 이 Base 클래스는 DSL이 변경되어 빌드할 때마다 변경되는 클래스이다.
그러나 이 Base 클래스를 상속하고 있는 하위 클래스는 DSL이 변경되어 빌드하더라도 변경되지 않는 클래스이다. 개발자들이 구현해 놓은 부분이 빌드할 때마다 초기화가 된다면 얼마나 끔찍하겠는가?
<그림 4>의 시퀀스 다이어그램을 놓고 보면 지금까지의 개발 방식과 별반 다를 것이 없다. 단지 바뀐 부분이라면 DAO 클래스가 Repository라는 이름으로 사용하는 것과 데이터베이스와의 인터페이스를 위하여 fornax-platform에서 제공하는 API를 사용하고 있다는 것이다.
fornax-platform에서 제공하는 API는 Hibernate 프레임워크 API를 이용하여 직접 구현하는 것이 가능하다.
Sculptor 툴에 의하여 자동적으로 생성된 Service, Entity, Repository 구성요소의 자바 소스를 살펴보면 <리스트 3>과 같다.
<리스트 2>의 DSL에서는 Planet Entity의 속성이 name과 message 뿐이었다. 그러나 Sculptor 툴에 의하여 생성된 <리스트 3>의 예제 소스를 보면 id, createDate, createdBy 등과 같은 속성이 자동적으로 추가된 것으로 알 수 있다. 이는 Entity 구성요소가 기본적으로 가지는 속성을 추가한 것이다.
<리스트4>와 <리스트 5>는 DDD 구성 요소 중 Repository와 Service에 대한 Base 클래스이다. <리스트 4>, <리스트 5>의 Base 클래스를 확장하여 추가적인 구현을 진행하면 된다.
Sculptor 이용한 개발 사이클
Sculptor 툴은 구현 클래스부터 단위 테스트를 위한 테스트 클래스까지 자동적으로 생성한다. 따라서 Sculptor를 사용하면 Test Driven Design(이하 TDD) 기반으로 애플리케이션을 구현하는 것이 가능하다.
TDD 기반으로 HelloWorld 예제를 구현하려면 먼저 PlanetServiceTest 클래스의 testSayHello 메소드를 <리스트 6>과 같이 구현한다.
<리스트 6>의 테스트를 실행하면 여전히 단위 테스트가 실패하는 것을 확인할 수 있다. 이 같은 이유는 테스트를 위한 테스트 데이터가 데이터베이스에 저장되지 않았기 때문이다. Sculptor 툴은 단위 테스트의 편의성을 위하여 dbunit 테스트 프레임워크를 이용하여 단위 테스트를 진행할 수 있도록 지원한다.
테스트용 데이터를 생성하기 위하여 src/test/resources/dbunit/PlanetServiceTest.xml 파일을 <리스트 7>과 같이 구현한다.
테스트 데이터까지 준비한 다음 마지막으로 구현할 부분은 PlanetServiceImplBase 클래스를 상속하는 PlanetServiceImpl 클래스이다.
<리스트 8>과 같이 PlanetServiceImp 클래스를 구현한 다음 <리스트 6>의 단위 테스트를 실행하면, 단위 테스트가 성공하는 것을 확인할 수 있다.
애플리케이션을 개발하다 보면 고객의 요구사항은 항상 변화하기 마련이다. 고객의 요구사항이 변경될 때마다 비즈니스 도메인을 수정할 수밖에 없으며, 이 같은 결과 DSL은 수시로 변경된다. 이때마다 지금까지 개발한 모든 소스를 초기화하고 재개발해야 된다면 얼마나 비효율적이겠는가?
Sculptor 툴은 DSL이 변경되었을 때 <리스트 9>와 같은 Maven 명령문을 이용하여 Base 클래스만 재생성하고 개발자가 구현한 소스는 그대로 유지하는 것이 가능하도록 지원하고 있다.
Sculptor 툴은 DDD 기반의 소스 코드를 생성하면서 단위 테스트 코드까지 자동적으로 생성하고 있기 때문에 지금까지 TDD 개발 사이클에 익숙해져 있는 개발자들이 쉽게 접근할 수 있다.
Sculptor의 가능성과 한계
Sculptor 툴은 지금까지 필자가 사용해왔던 많은 소스 생성 툴 중에서 가장 만족할 만한 툴이다. 특히 DDD에 대한 많은 관심을 가지고 있는 현 시점에서 DDD 기반으로 소스를 생성한다는 것은 큰 매력으로 다가온다.
하지만 모든 툴이 우리들이 원하는 장점만을 제공하는 것은 아니다. Sculptor 툴 또한 다음과 같은 문제점으로 인해 실무 프로젝트에 적용하는데 한계점으로 작용할 것으로 생각한다.
첫째, 생성되는 소스 코드의 량이 너무 많다. 모든 소스 코드가 Base 클래스와 이를 상속하는 구현 클래스로 나뉘며, 설정 파일 또한 일반적인 개발 방식보다 두 배 이상 많이 생성된다.
둘째, 생성되는 소스 코드가 fornax-platform.org API에 종속된다는 것이다. 특히 Repository 구성 요소의 의존도는 상당히 크다. 만약 fornax-platform.org에서 제공하는 API에 문제가 발생할 경우 문제를 해결하는데 더 많은 시간을 투자할 가능성도 있다.
셋째, 개발자들이 DSL 문법을 새롭게 익혀야 한다는 것이다. DSL 문법이 DDD 구성요소들을 기반으로 하고 있지만 배우는데 많은 시간을 투자해야 하는 것은 사실이다.
이 같은 한계점으로 인해 Sculptor 툴을 실무에 바로 적용하는 것은 힘들 것으로 생각한다. 단, DDD에 대한 공부를 시작하기 위한 수단으로 Sculptor 툴을 통하여 생성되는 소스를 활용하는 것은 좋은 전략이 될 것이라 생각한다. Sculptor 툴의 아이디어를 발판으로 각 프로젝트만의 소스 코드 생성기를 만드는 것 또한 좋은 전략이 될 것이다.
다른 개발자가 만들어 놓은 결과물이 만족스럽지 않다면 내 자신이 한번 만들어보는 시도를 한다면 국내에도 Sculptor 툴과 같은 좋은 툴이 나올 수 있지 않을까? @
참고자료
1. Sculptor Homepage: http://fornax-platform.org/cp/display/fornax/Sculptor+%28CSC%29
2. Sculptor 툴의 HelloWorld 예제: http://fornax-platform.org/cp/display/fornax/3.+Hello+World+Tutorial+%28CSC%29
3. Sculptor 툴을 이용하여 개발 생산성 향상: http://www.theserverside.com/tt/articles/content/ProductivityWithSculptor/article.html
4. Domain Driven Design, Eric Evans, 2006, Addison-Wesley
5. POJOs In Action, Chris Richardson, 2006, Manning
* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
지금 뜨는 기사
이시각 헤드라인
ZDNet Power Center
