블로그 이미지
Max.

calendar

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Notice

2009.09.12 08:19 개발관련
저에 부터, 나는 인터넷의 좋은 정보는 공유되어야 한다.라는 생각을 가지고 있다. 그냥 공유가 아니라 보다 더 많이 공유되어야 한다는 생각이다. 펌글이 그런 역할을 하지 안나 생각된다. 그래서 펌질을 했다. 아래 동영상은 InfoQ에 올라온 Responsibility Traps에 대한 Strategic Design을 설명한 Eric Evans의 동영상이다.  특히 개발자중 설계를 하는 사람들에게 좋을것 같다. 영어의 압박은 학습의 승화로...


Strategic Design - Responsibility Traps

Presented by Eric Evans on Sep 03, 2009 05:18 PM

Summary
Eric discusses the need for strategic thinking an how early design decisions have major impact on the organization and the entire development process. He uses the lens of DDD Strategic Design principles (emphasizing "Context Mapping" and "Distilling the Core Domain") to show how to avoid strategic failures and achieve strategic successes. Winning strategy starts with the domain.



(동영상이 나온지는 좀 되어서 뒷북이긴 하지만, 공유되어야 한다는 Responsibility Traps(?)를 긍정적으로 이해하길....)

신고
posted by Max.
2008.01.28 17:03 이전글(~2009)
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 인기, 의지 등이다. 최근에 알려진(알려졌지만, 공개되지는 않은) ROO AF(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가 나올수 있으니 말이다.)
- 지금 먹기엔 아직 떨뜨름한 감 처럼 느껴진다.-


신고

'이전글(~2009)' 카테고리의 다른 글

Spring JMS 기본예제-1  (6) 2008.02.04
Spring OSGi 학습하기 좋은곳은?  (7) 2008.01.29
먹기엔 덜익은 DDD 와 Rich Domain Model  (4) 2008.01.28
새해다짐  (2) 2008.01.11
행동가에 대한 단상  (0) 2008.01.08
신경쓰이는 10년의 계획  (0) 2008.01.07
posted by Max.
2007.12.21 18:10 이전글(~2009)

@Configurable는 Spring2.0에서 지원되는 어노테이션이다.
DDD에서 Rich한 Domain을 만들기 위해서는 필수인듯 하다.
그러나 아직 실무(?)에서는 어노테이션을 지원하는 JDK 버젼이 적을뿐만 아니라 Spring 기반의 솔류션을 만든다면 범용(?)적인 환경에 적응할수 있어야 한다.

따라서 JDK5.x 이상의 환경과 Spring2.0 이상의 환경을 요구하는 @Configurable은
Rich한 Domain을 만들기 위해서는 그림에 떡이 될수도 있다.

@Configurable 효과를 낼수 있는 방법이 있을것이다. 물론 복잡하지 않는 범위 내에서 말이다. 찾아본 결과 MethodInvokingFactoryBean를 쓰면 비슷하게 구현할수 있다는걸 알게 되었다.

아래는 테스트한 내용이다.

1. XML
 <bean id="articleRepository" class="com.shyun.board.article.domain.hibernate.ArticleRepositoryHibernate"
   p:sessionFactory-ref="sessionFactory"/>
 <bean id="articleFinder" class="com.shyun.board.article.domain.hibernate.ArticleFinderHibernate"
   p:sessionFactory-ref="sessionFactory"/>  

 <bean id="articleRepositoryInjector"
   class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
   <property name="staticMethod">
     <value>com.shyun.board.article.domain.Article.setArticleRepository</value>
   </property>
   <property name="arguments">
     <list>
       <ref bean="articleRepository"/>
       <ref bean="articleFinder"/>
     </list>
   </property>
 </bean>

 

2. Article.java

public class Article {
 ........
 private static ArticleRepository articleRepository;
 private static ArticleFinder articleFinder;
 public static void setArticleRepository(ArticleRepository ar, ArticleFinder af){
  articleRepository = ar;
  articleFinder = af;
 }
 ........
 public Article saveArticle(Article article){
  return articleRepository.saveArticle(article);
 }
 public void removeArticle(Article article){
  articleRepository.removeArticle(article);
 }
 public List<Article> findArticleList(int currentPage, int countPerPage){
  return articleFinder.findArticleList(currentPage, countPerPage);
 }
 public Article findArticleById(Integer articleId){
  return articleFinder.findArticleById(articleId);
 }
.......
}


 

3. test case

public void testSaveAndReadAndRemote(){
  Article article = ArticleFixture.getArticle();
  Article articleSave = article.saveArticle(article);
  articleSave.setTitle(article.getTitle()+"(수정)");
  articleSave = article.saveArticle(article);
 
  ff("title ",articleSave.getTitle());
  ff("aritcle id",articleSave.getArticleId());
  assertEquals(article.getArticleId(), articleSave.getArticleId());
 
  article.removeArticle(article);
        try {
         article.findArticleById(article.getArticleId());
            fail("User found in database");
        } catch (DataAccessException dae) {
            ff("Expected exception: ",dae.getMessage());
            assertNotNull(dae);
        }
 }
 public void testFindArticleList(){
  Article article = ArticleFixture.getArticle();
  article = article.saveArticle(article);
  int currentPage = 0;
  int countPerPage = 1;
  List<Article> list = article.findArticleList(currentPage, countPerPage);
  ff("aritcle list size",list.size());
  assertEquals(1, list.size());
 
  article.removeArticle(article);
 }

4. 결과 화면

사용자 삽입 이미지


풍부한 도메인 만들기 위해서 환경이 된다면 @Configurable를 쓰는것이 좋지만, 환경이 안된다고 해서 포기할 필요는 없다. 위와 같은 방법 이외에도 Spring을 잘 안다면 좀더 쉽게 구현할수도 있을것이라고 생각된다.


Resouce
http://forum.springframework.org/search.php?searchid=1255212
http://joesbitbucket.blogspot.com/2006/08/how-to-inject-dependencies-into-domain.html
http://chris-richardson.blog-city.com/migrating_to_spring_2_part_3__injecting_dependencies_into_en.htm

신고
posted by Max.
2007.11.12 10:20 이전글(~2009)
최근 찬욱님의 ROO Architecture review 라는 글을 보고 Demo에 적용해 보기로 했다. 해당글에서 눈에 띄는 것은 두가지가 있었다.

첫째 Repository에서 Finder의 분리이다. 어쩌면 이 당연한 현상을 왜 생각하지 못했는지 나 자신이 얼마나 생각없이 개발하는지 알수 있는 대목이다. 실무 개발시 주도메인은 상당히 많은 finder를 Repository에 만들수 밖에 없다. 그만큼 각양각색의 조건들이 포함된 Select가 많이 있기 때문에 그렇다. 이 개념은 당장 도입해도 좋을 개념이다. 사실 최근 프로젝트에서 엄청나게 많은 finder를 넣은 Repository를 만들었다. Repository라고 부르기에도 민망할정도로....

둘째는 DTO assembler라는 것이다. 이것은 DO를 DTO로 값을 복사해주는 역할을 한다. 이것 자체의 구현 역시 어렵지 않다. 그러나 이것이 주는 의미는 ROO에서 의미하는 바가 크다. 보통 우리가 말하는 Service Layer 에서 DO를 쓴다. 이것은 DTO에서 내부적(?)으로 가져다 쓰는 구조 이다. 즉 모든(3Tier)계층에서 DO를 쓴다. 그러나 ROO에서는 DO를 쓰지 않는다. 엄격히 Domain Layer 아래로 격리시킨다. 따라서 Biz Layer(이것이 다른이름으로 불리던 어쩌던 간에 비지니스로직을 수행하는층을말함)에서는 DTO 를 쓴다. 핵심은 여기서 나온다. 이렇게 DTO를 씀으로써 번거러움이 가중되고, 더 세분화 함(Finder등)으로써 늘어나는 클래스를 어떻게 할것인가?
ROO에서는 이런것들을 Code Generation 으로 해결한다. Finder를 수동(?)으로 구현하거나 DTO를 Dozer를 써서 이것을 수동(?)으로 구현하는것은 기존에 했던 방법보다 손이 많이 가며 그리큰 매력을 느끼기 힘들다.

그러나 이들을 자동화해 버린다면? DTO, Finder,XML 심지여 TestCase까지 자동으로 생성해 준다면? 멋지다. 이것이 ROO의 가장큰 특징이 아닐까 한다. CG(Code Generation)에 대해서는 아직 아는바가 없다. Toby님 글에 '아주 정교하게 구현되어 있다'라는 언급만 나왔을뿐 뭘 어떻게 하는지 알기 힘들다. ROO가 언제 공개될지, 아니면 영원히 오픈 안될수도 있지만, 지속적으로 주시해볼 필요가 있다.

일단 두가지 특징을 수동(?)으로 만들어 Demo에 적용해 보았다. 그냥 그저 그렇다 ㅡㅡ;;
역시 자동화가 Key 인것 같다. Maven과 eclipse에 대한 기능을 잘 익혀두어야 한다. ROO가 나올때를 대비해서 말이다.

(그나 저나 앞으로 ROO에 대한 소식을 들을만한곳이 없다. 어디서 소식을 들어야 할지...Toby님도 잠적하시고...-,.-a )
신고
posted by Max.
2007.11.06 09:53 이전글(~2009)

저마다 생각하는 Best Practice가 있을 것이다.
Spring을 이용해서 자신만의 Best 아키텍처를 지속적으로 발전시키는건 또하나의 재미있는 일이다.
이리 저리 무언가 꺼리를 생각하던중 눈에 들어오는 것이 생겼다.
ROO.....
ROO는 과거 토비님이 TSE2006을 다녀와서 블로그 언급한적(1),(2)이 있다.
대략 '나중에 공개되니 그때한번 보자' 라는 생각으로 정리 되었던 기억이 난다.
Raible에서도 이런 저런 댓글이 많지만 여전히 나에겐 매력적인 놈으로 보인다.

최근 관련해서 찬욱님이 의욕차게 글을 올려주고 있다.
ROO에 대한 스터디 내용인데 재미 있고, 실무에 응용 할만한 내용도 있다.
핑계꺼리만 찾는 나보다 실천하는 그의 노력과 열정이 부럽기만 하다.

이쯤 되면.... 나도 시간을 만들어서라도 관련 코드를 만들어 봐야 할텐데...


신고
posted by Max.
TAG ddd, ROO
prev 1 next