DTO(Data Transfer Object)

참조 :
http://martinfowler.com/eaaCatalog/dataTransferObject.html
http://en.wikipedia.org/wiki/Data_Transfer_Object
http://www.theserverside.com/discussions/thread.tss?thread_id=32389

찬욱군이 요즘 DTO Assembler를 만들고 있는 것 같습니다. 저는 DTO 개념이 없기 때문에, 오히려 더 복잡해 보이는데 왜 저렇게 해야 되는거지 궁금해 했습니다. 대체 DTO가 뭐길래…그래서 찾아봤습니다.

사용자 삽입 이미지위 그림은 첫 번째 링크 마틴 파울러 eaa 카탈로그에서 가져왔습니다. 원격 호출을 할 때 호출의 수를 줄이려면, 한 번에 여러 객체를 가져와야 하는데, 메소드가 오직 하나의 객체만 반환할 수 있는 자바같은 언어들은 그런 것이 불가능하기 때문에 고안한 것이 DTO 입니다.

즉, 필요한 정보만 모아놓은 객체가 되겠죠. 따라서 서버 측에서는 이런 객체(DTO)를 지원하기 위해 여러 객체의 정보를 가지고 DTO를 만들어주는 Assembler라는 녀석을 제공해야 하고, 지금 찬욱군이 이 녀석을 만들고 있는 것 같습니다.

두 번째 링크인 위키피디아의 정의를 보면, DAO, 비즈니스 도메인 객체(DO), 그리고 DTO의 차이를 매우 간략하게 말해주고 있습니다.

The difference between Data Transfer Objects and Business Objects or Data Access Objects is that DTOs do not have any behaviour except for storage and retrieval of its own data (accessors and mutators).

무언가 혼란스러움이 생기기 시작합니다. 이제까지 도메인 객체(DO)라고 구현했던 녀석들과 DTO와의 차이가 없습니다. 그 녀석들(DO)도 단순하게 프로퍼티와 세터 게터만 가지고 있었으니까요. 그럼 DTO와 별단 차이가 없기 때문이죠. 이것참… 어쩐지 도메인 객체가 너무 횡하다 했습니다.

MemberDao.save(Member) 같은 메소드는 뭔가 어색하고 Member.join() 하면 그냥 DB 저장이 되야 어색하지 않은데 말이죠. MemberService.getMember(id)를 호출하면, Member 도메인 객체가 아니라, 사용자가 보기 원하는 정보만을 담은 Member DTO를 넘겨주는 것이였군요. 이런식으로 하면 도메인 객체 계층을 눞힐 수 있겠군요.(세워두는 것이 아니라..) 찬욱군이 그린 ROO 아키텍처가 이해가 가기 시작합니다.

저는 저 위의 그림의 Assembler보다 Facade가 더 궁금하네요. 역시 그림도 좋은데 코드가 있어야… 좀 더 명확할텐데 말이죠. DTO와 Assembler 그리고 Facade를 잘 활용한 애플리케이션 코드를 보고 싶네요.

DDD: putting the model to work

59분이라는 비교적 짧은 시간 동안 에릭 에반스가 발표한 자료가 올라왔었네요. Spring 2.5 관련 아티클 보러갔다가 DDD 발표 동영상 발견하고 이거 구경하고 있습니다.

발표자를 중심으로 찍은 화면이 재생되고, PPT는 플래시로 특정 시간마다 한 장씩 자동으로 보여줍니다. 오~ 발표자료 보여주는 데에도 상당히 신경을 쓴 InfoQ 멋집니다.

보러가기

이런.. 마지막에 조금 쉬었다가 2부에서 이어진다고 하는데, 아직 안 올라왔네요.

도메인, 모델, 유비쿼터스 언어, 모델 이름 선택에서 중요한 것, Context Map을 예제를 가지고 설명해줬습니다. 매우 차분하게 말씀하시네요. 목소리 톤이 약간 졸리기도 합니다.

Building Domain Knowledge

비행기 모니터링 시스템을 구축하려고 한다.
특정 지역에 떠있는 모든 비행기들의 루트를 파악하여 충돌할 가능성이 있는지 나타내는 모니터링 시스템을 구축하는 것이 프로젝트의 목표다.

앞에서 얘기 했듯이 도메인을 이해하는 것부터 시작해야 한다

이 분야 도메인 전문가는 비행기 통제사다. 통제사와 대화를 하는 도중 비행기 이륙과 착륙에 대한 이야기를 많이 듣게 되었다. 그리고 실제 충돌이 이착륙 대기 중일 때 발생할 위험이 있다고 한다.

통제사와 당신은 모든 비행기가 목적지와 출발지가 있다는데에 동의했다. 그래서 다음과 같이 그렸다.

bl120.bmp
실제 비행기가 공중에 있을 때는 어떤 일이 벌어질지 물어본다. 통제사는 각각의 비행기에는 정해진 비행로가 있다고 한다. 대화를 좀더 듣다보니 경로(Route)라는 흥미로운 단어를 들었다. 이 것이 실제 비행중에 가장 중요하다고 생각했고 비행기가 목적지와 출발지와 직접적으로 연관관계를 갖는 것이 아니라 경로(Route)와 연관을 맺고 이 경로가 목적지와 출발지와 연관을 맺도록 하는 좀 더 명확한 표현 같다.
bl121.bmp
좀 더 이야기를 해보니 이 경로는 여러 세부 경로로 나뉘어져 있다는 것을 듣게 된다. 즉 경로가 고정된 포인트로 이루어 진 것으로 파악이 되며 목적지와 출발지는 그 고정된 포인트 중 두 개로 파악할 수 있다.
bl122.bmp고정된 위치는 3차원으로 표기 할 수 있다.(경도, 위도, 고도?) 하지만 통제사는 비행기를 지구 표면의 평면으로 투사한 곳에 점으로 인식하고 있다는 것을 알게 됐다. 따라서 2차원 점(경도 , 위도만?)으로 표현되도록 수정하였다.
bl123.bmp

여기까지 진행 한 것을 살펴보면 굉장히 많은 시간을 소비하는 것처럼 보이고 실제로도 그렇치만 당연히 이렇게 해야만 한다. 소프트웨어의 최종 목적은 현실의 도메인과 관련된 비즈니스 문제를 해결하는 것이기 때문에 도메인에 익숙해 져야한다.

What Is Domain-Driven Design

소프트웨어 개발은 진짜 세상에 존재하는 프로세스를 자동화 시킨 것 또는 현실의 비즈니스 문제에 대한 솔루션을 제공한다.

좋은 소프트웨어를 개발하기 위해서는 그 소프트웨어가 무엇을 하는지 완벽히 알아야 한다.

소프트웨어 프로젝트를 시작할 때 도메인에 집중해야 한다. 도메인에 깊게 뿌리를 두지 않은 소프트웨어는 시간이 갈 수록 변화에 잘 적응할 수 없다.

추상화란? 도메인에 대한 모델이다. Eric Evans는 도메인 모델은 특정 다이어그램이 아니라고 한다. 영어 문장이나 잘 작성된 코드 처럼 도메인을 표현할 수 있고 의사소통이 가능한 다이어그램이다.

모델에 무엇을 표현하고 무엇을 표현하지 말지 정해야 한다.
다른 사람과 의사소통 할 수 있도록 표현이 가능해야 한다. 그래픽을 사용하는 방법과 글로 표현하는 방법이 있다.
=> We need to communicate the model

모델을 만든 뒤에는 코드 설계(code design)를 시작할 수 있다. 소프트웨어 설계는 큰 그림 부터 그리고 코드 설계는 세밀한 부분부터 그린다.
=> 좋은 코드 설계 없이 만들어낸 최종 산출물은 좋을 수 없다.

Waterfall 과 Agile 방법론의 단점들
Waterfall : feedback이 없다.
Agile : analysis paralysis(아무도 설계에 대한 결정을 하려 들지 않는다.), 초기에 전체 윤곽을 파악하기 힘들다.
=> DDD는 적용이 되면 어떤 개발 공정의 능력도 향상 시킬 수 있다.

DDD conbines design and development practice, and shows how design and development can work together to create a better solution.