ROO는 DDD의 적용 기술의 하나이다. 아키텍처적인 접근방법.

4개의 분리된 layer를 가진다. UI, Middle-Tier Exporting, Domain Model, Persistence.

DAO -> Repository(Finder per DO and Shared). Domain Model layer -> Business Logic을 가진다. DDD의 원리 그대로. DO는 Middle-tier에서 DTO의 형태로 존재한다. 으흠?

전통적인 접근법과 비교

Transparent persistence: Tr(Not)/ROO(Used)
Persistent Lyaer Name : Tr(DAO)/ROO(Repository)
BusinessLogic : Tr(SL) / ROO(DO Layer)
Form backing object : Tr(DO Layer)/ROO(DTO Layer)
DO and SL pattern names: Tr(Misused)/ROO(Correct)

ROO approach is justifiable

Laers have well-defined purpose (OO)
Types mostly auto-generated (efficiency)
Architecture uses pattern

Pattern Used in ROO

Strategy
Facade
Domain Object
DTO
DTO Assembler
Repository

Code Generation Considerations

Quality codew generation is attainable. 잘못된 code generation은 당연히 불편하다. 안정된 아키텍처기반의 접근이 필요하다. (A whole architecture approach)

Target: source, Java bytecode, XML. Tool support는 필수. 품질이 문제다.

How ROO Differs

철학: Domain first, infrastructure second. CoC. OO and modern capabilities.

Efficiency우선.

데모를 screencast방식의 비디오(avi)상영으로 진행하고 있다. 시간을 절약하면서도 효과적인 전달을 위한 괜찮은 방법이다. 그런데 고해상도에서 레코딩한 화면이라서 그런지 코드의 글자가 약간 깨져보인다. 눈이 아프다. :( 으음.. 내가 OSAF/OSAF Tool에서 궁극적으로 하려고 했던 것을 이미 다 만들어놨다. Maven과 Eclipse를 이용한 tool지원. CoC. Code generation. DDD, GenericEnum 등등. 으으으음..

Domain object의 validation logic이 constructor에 들어간다. 흠흠.

Hibernate는 xml을 이용한다. 하지만 자동으로 생성을 해준다.

CoC의 개념이 많이 적용되어있다. 패키징설정등 각종 관례들이 효율적으로 설계 되어있다. ROO는 transparent persistent를 사용한다. 따라서 ORM의 장점을 다 취할 수 있다. DO설계에 유리하다. 다형성, 상속 등등. 이런면에서는 Repository의존적인 접근법을 주장하는 Ramvinas와는 다르다. FinderSpecification이라는 것을 만들어서 그 안에 Finder에 대한 정의를 만들어 넣게 한다. Repository를 만드는 방법도 매우 독특한 구조로 정교하게 설계되어있다. 상세한 기능을 CoC개념으로 설계하고 구현해 놓은 것이 마치 RoR을 보는 듯하다.

으음.. 상당히 독창적인 설계 아이디어들이 많이 들어있다. 소스코드를 구해서 본격적으로 살펴봐야할 것 같다.

Type

ROO의 핵심이 되는 개념중의 하나.
Details objects를 CGM metadata로 사용한다. ROO는 code generation을 매우 정교하게 할 수 있도록 설계되어있다.

Custom Finder, Hibernate User Type Mapping XML, DTO, Middle Tier Facde, test Data, Integration Test등이 ROO가 generate하는 대상이다. (현재버전? 앞으로 더 발전할거다)

Maven Archetype

STE에는 maven사용을 권장하는 강사들이 많다. 으흠. 다들 사용목적은 조금씩 다르지만.

Plugin적용. ROO Target은 Maven을 이용해서 Eclipse에 적용되어있다. Eclipse는 auto-refresh를 지원한다!!

Key Principles

DAO: transparent persistence (essential)
Domain objects는 UoW(Unit of Work)에 attach되어있다.

Repository

Global, shared repository. read*, find*, make* naming convention. T.Persistence.

Finders

Specification을 통해서 Criteria와 유사한 방식으로 metadata를 만들면 된다. FinderDetails. Acegi기능이 추가되어있다.

Hibernate Mixing

ROO will stub the Hibernate mappings.
ROO will wirte UserTypes

Middle Tier Exporting

facade는 Respository에 read*를 바로 호출할 수 있다.
Aggregate and DTO return type관리가 필요하다.
으음. 진도가 무지 빠르다.

Domain Object

field level access를 이용한다. state managed fields를 구분한다.

UoW의 역할은 flush event를 호출하는데 사용되는 것이다.
Domain object는 UoW에서 detach되지 않는다.

Domain Object Delegate Methods

DTO의 컨버전이 자동으로 일어난다. 으흠.. ROO는 DTO기반의 DDD를 지지한다.

Posting[] Interest.compute(Account) -> PostingDtop[] compute(InterestDto, AccountDto);

DTO Assembler 

Dozer를 사용. DTos to DOs. DOs to DTOs.

Aggregates

이것은 뭐 기존접근법과 유사하다. Module개념으로 분리.

Middle Tier Metadata

JMX로 export될 수 있다. jconsole등을 이용할 수 있다. 역시 흥미로운 접근 방법이다. DWR의 Ajax console을 보는 듯하다.

(시간이 얼마없어 많이 생략 -_-)

적용사례

호주에서 제일 큰 마트인 (점포 3000개). Woolworths에 적용해서 성공.

 

방대한 규모의 프레임워크를 데모까지 포함해서 1시간반에 설명하느라 정말 빨리 진행이 됐다. Ben의 말도 무척 빠르다. 호주 액센트로 말 빨리하면 거의 죽음이다. -_-; 한줄 입력할 시간도 안되서 페이지가 넘어가니 정리가 왕창 빼먹고 엉망이다. 정리의 도사 Matt 것을 나중에 참조해 보던가 해야겠다.

결론은? ROO는 오픈소스 프로젝트가 아니닷! 그래서 공개도 되어있지 않다. 현장에서 고객의 시스템을 개발하면서 발전시켜온 프레임워크라서 지금 바로 공개하기는 힘들다고 했다. 만약 요청이 많이 있다면 confidential한 부분을 제거하고 오픈소스 프로젝트화 할 생각이 있다고 했다. 하지만! 계속 고객사이트에서도 발전시켜 나가는 것이라 버전관리 등등이 어찌될지 모르겠다. 어쩜 OSAF랑 상황이 똑같네 -_-;

OSAF는 전통적인 Spring/Hibernate 아키텍처에 Context개념과 JDK5의 Generic등의 지원을 강화해서 만든 프레임워크이고 ROO는 JDK1.4이하 버전에서(고객사의 환경이 아직 그럴테지) 동작하면서 DTO를 활용한 DO 레이어의 도입과 정교하게 설계된 code generation기술을 중심으로 만들어진 것이다. ROO의 역사를 설명하면서 얘기했지만 고객의 가려운데를 긁어주다보니 만들어지고 발전해온 결과가 ROO이다.

이번 컨퍼런스에서 DDD와 관련된 실제 적용방법을 여러가지를 알게 되었다. 다 나름대로 장단점이 있을 것 같은데 다양한 시도를 통해서 나에게 맞는 최적화된 전략을 찾아보는 것이 앞으로의 나의 과제가 될 것이다.

 

Related posts:

  1. TSE2006 셋째날 세션1 – Applying DDD int the Enterprise with AspectJ
  2. TSE2006 넷째날 세션1 – Meeting Requirements through Acceptance and Stress Testing
  3. Spring ROO 대충대충 분석 (4) ROO의 미래와 의의
  4. Spring ROO 대충대충 분석 (2) ROO란 무엇인가?
  5. Spring ROO 대충대충 분석 (1) 공개과정
  6. 뒤늦게 쓰는 SpringOne 2007 셋째날 후기
  7. Spring 3.0 (17) Orm 모듈의 선택 라이브러리 분석
  8. Spring ROO 대충대충 분석 (3) ROO의 Inter-type declaration
  9. The Spring Experience 마지막날
  10. The Spring Experience 둘째날
  11. 기본에 충실하자? OO가 중요하다?
  12. Domain Model vs. DTO
  13. 테스트 할 수 없는 것을 테스트 하기. Spring ROO와 static method mocking.
  14. Spring 3.0 (9) Beans 모듈의 선택 라이브러리 분석
  15. Spring 3.0 (40) Spring ASM 모듈의 소스는 어디에?

Facebook comments:

to “TSE2006 넷째날 두번째 세션 – ROO”

  1. 이글에 대한 상당부분 이해가 안되지만,
    OSAF가 기대 됩니다. ^^;;

  2. 아침부터 글들 읽느라 눈 빠지는 줄 알았네, 쩝.. 하루저녁 안본 사이에 무슨 글을 이렇게 많이 올리는 거예요.. –+

  3. This is a comment to the admin. Your website is missing out on at least 300 visitors per day. I have found a company which offers to dramatically increase your visitors to your site: http://nsru.net/188x They offer 1,000 free visitors during their free trial period and I managed to get over 30,000 visitors per month using their services, you could also get lot more targeted traffic than you have now. Hope this helps :) Take care.

  4. mbt schuhe TSE2006 넷째날 두번째 세션 – ROO » Toby’s Epril

  5. sperry shoes TSE2006 넷째날 두번째 세션 – ROO » Toby’s Epril

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha