DDD책을 보면서 패러다임이 많이 바뀌었는데, 내가 잘못 이해를 한것이 아닌가 고민스러울때가 있었다.
spring2.0 overview를 통해서 DDD를 나에게 알려주었던 국내에 DDD전도사 토비님이 이번에는 The Spring Experience2006까지 가셔서 많은 정보들을 블로그에 포스팅을 하고 있습니다.
토비님 블로그에서 다음과 같은 정리는 내가 제대로 이해는 했다는 생각을 갖게 했다. 당연한 이야기지만, 어떤식으로 엔트리 포인트를 정할 것인가? 관계를 어떻게 가져가야 정말 우리가 원하는 Rich한 모델을 만들수가 있는가? 개발을 하다가 보면 고민이 많다.
사실, 개발하면서 처음 생각한 디자인하고, 계속 달라지는 느낌도 많이 받았다. 물론, 개발자와 domain expert와 대화를 하면서, 풀어나간 Eriv Evans의 이야기들처럼 누군가의 대화는 아니었지만, 나 자신이 하면서 좀더 스키마가 생기면서 바뀌는 코드들의 느낌이라고 할수 있다.
또 한가지 강조한 것은 Entity, Value Object, Service를 잘 구분하는 것이다. 특히 Entity와 immutable한 VO를 모델에서 적절하게 선별해 내는 능력이 중요하다. Entity중에서 root역할을 하는 것을 aggregate entity라고 한다. Serivce layer에서는 주로 이 aggregate entity를 이용해서 domain layer에 접근을 한다. 동시에 repository가 매칭되는 기준이 되기도 한다.
aggregate entity는 너무너무 중요하다. service layer의 인터페이스에는 거의 aggregate entity가 보일 것이기 때문에 aggregate entity를 distill하는 것은 자연스럽게 인터페이스 설계에 반영이 되기 때문일 것이다.
DDD에 대한 흥미로운 대화(토비님과) http://younghoe.info/362 토비님과 영회님 두분 메신져로는 이렇게 훌륭한 대화를 할수 있다니, 정말 못말리는 두분이네요. 정말 흥미로운 대화입니다.Kent Beck이 DDD를 극찬을 했다는 얘기는 DDD Beliver들에게 더 힘을 실어주는 이야기군요.
제가 막연하게 생각했던 이야기를 대화를 통해서 잘 풀어주셨네요.
Toby님의 말: Eric이 강조한 것은 Modeling은 그 목적을 분명하게 가지는게 중요하다는 겁니다. Toby님의 말: Keith는 그것을 영화를 만드는 것에 비유하기도 했죠 Toby님의 말: 하나의 팩트를 가지고도 다양한 영화를 만드는 것처럼. [永會] 님의 말: 영화요? Toby님의 말: real world의 특별한 관점을 가진 snapshot이라는 뜻이죠 [永會] 님의 말: 아.. 모델링이 스냅샷이라구요 Toby님의 말: 네.. 목적을 가진 스냅샷이죠. Toby님의 말: 목적에 따라서 다양한 모델이 나올 수도 있다는 거고요 [永會] 님의 말: 네.. 목적..
영어가 좀되고, Spring Experience에 참가해서 실시간으로 포스팅을 하는 토비님이 부럽기도 하다. 내년에는 정말 열심히 영어공부를 해서, 빠른 시간이내에 해외 컨퍼런스에 가서 같이 얘기를 하고 싶다.
최근 테스트케이스에 큰 관심을 가지고 연구(스터디) 중에 있는데, 역시 중요하다는 생각을 다시 한번 하게 된다.
OOP, DDD, Units Test, 테스트가 쉬운 코드, 인터페이스 지향 프로그래밍, Design Pattern 등등의 상관관계들을 정리하는 시간을 가질 필요는 있다.
IoC컨테이너 spring을 가지고 개발을 하게 되면, 좋은 디자인의 코드, 테스트 하기 쉬운 코드, 좋은 코딩습관을 가지게 된다는 것에 후한 점수를 주고 싶다.
대전제를 3가지정도만 적어보자. 아마 훨씬 많은 것이다. 1. 중복코드를 제거하자. 중복이 없다면, 코드를 관리하기가 쉽다. 관리비용이 절감된다. 2. 유연한 코드 개발로 변화에 빠른 대응이 가능한 개발을 할수 있는 코드를 만들자. 3. 서비스하는 코드와 테스트하는 코드는 하나이다.
결국 목적은 하나라는 생각이지만, 그것들간에 긴밀한 상관관계를 생각해보자.
Domain, Object, Class, Unit 우리가 많이 사용하던 단어이지만, 다시 한번 의미를 되새겨 볼만한 충분한 가치가 있을 것이다.
Whiteboard (with a digital camera for persistence)
IDE
Unit tests
Our Mouths and Ears
ROO(real object oriented) architecture?
That means we swapped out those anemic domain objects, fat services, and those repetitive DAOs for rich domain objects that utilize transparent persistence and encapsulate business rules.
Eric Evans is the author of "Domain-Driven Design: Tackling Complexity in Software," Addison-Wesley 2004.
Since the early 1990s, he has worked on many projects developing large business systems with objects with many different approaches and many different outcomes. The book is a synthesis of that experience. It presents a system of modeling and design techniques that successful teams have used to align complex software systems with business needs and to keep projects agile as systems grow large.
Eric now leads "Domain Language", a consulting group which coaches and trains teams applying domain-driven design, helping them to make their development work more productive and more valuable to their business.
처음에 PC를 상대로 여러가지 액션이나 기술들을 익혀가고 있는데, 정말 긴 시간동안 한번도 이기지 못 했다. 처음 게임을 할때는 사람보다는 컴퓨터가 더 어렵다...T.T
난 변화를 꾀해야 했다. 이 멍청한 컴퓨터에게 계속 질수는 없지 않은가? 게임을 자세히 보니, 단축키가 존재를 했다. 모든 단축기가 그렇듯이 비교적 쉽게 익힐수 있게 step by step으로 대부분의 액션들을 할 수가 있었다.
단축기를 익히는데 시간은 조금 걸렸지만, 단축기가 어느정도 익숙해질 무렵, 난 컴퓨터를 이길 수 있게 되었다.
난 첫승을 하는 순간에 엄청난 짜릿함에 스타의 마력에 점점 빠져들었다. 그 다음 친구와 함께 베틀넷에서 게임을 하게 되었다. 역시~ 맨날 패배~ 밤새 게일을 해도 매번졌다. 친구와 나는 좀더 연구를 해서 한가지씩 더 배우기 시작했다. 기술이라는 것이 단축기...-.-
베틀넷에서 게임을 하니, 더 긴박한 순간이 자주 찾아왔고, 단축기를 쓰는 속도도 제법 빨라져
졌다. 그 다음 빌드오더를 학습하면서 서서히 중수의 길에 오르기 시작했다. 그후 친구와 함께 길드를 만들어서, 아주 흥미진진한 게임도 많이 했고, 아이디 하나는 2000승이 넘는 것도 있었다. 스타를 하는 평민 중에서 거의 열반에 경지에 올랐던거 같다.
최근 2년간 거의 게임을 하지 않았다. 시간도 없었고, 가정이 생기면서 밤새 오락하는 것은 별로 바람직한 일이 아니라, 피하기도 했다. 얼마전 추석이라 처가댁 가족모임에 가서 나이 또래가 비슷한 사람들끼리 스타를 했다. 그래도 왕년에 조금 했는데, 2년이 지나도 잘 할수 있겠지라는 생각은 이내 처참하게 무너졌다. 일단, 단축기가 거의 생각이 안 났다. 음....일꾼 만드는 것은 이내 적응이 되었지만, 기타 유닛에 대한 컨트롤이 어려웠다. 빌드오더고 뭐고, 초반에 밀리면서 5판내리 초반에 eli를 당했다...T.T
아마 단게임당 게임시간이 늘어갔으면 감이 찾아오겠지만, 그러기도 전에 무너져버렸다. 나의 상황을 그 누구도 이해를 해주지 않았다. 5게임을 했지만, 내가 실질적으로 게임을 하는 시간은 20분도 되지않았던 것이었다.
갑자기 오만가지 생각이 났다. "역시, 스타는 자리가 중요해..항상 상대편에 둘러 싸여져 있으니, 첫번째 표적이 되는군"
나도 제법 승부기질이 있는 편이라, 속으로는 열불이 났다. 마은이 조금 진정이 되었을때 다시 한번 생각을 해봤다. 과연, 위치만 안 좋았던 것일까? 그렇다, 단축키!!! 단축키를 안써서 상대보다 더 빠른 대처를 할수 없었던 것이다. 이 얘기는 오랫동안 스타크래프트 실무(?)를 안 했던 것이다. 동영상도 온게임넷이나 기타 동영상을 통해서 가끔 봤기때문에 내 생각은 임요환이었다...^^V
얘기가 길었다. 본래 이 글을 쓸려는 의도에 연관을 지어보자.
이클립스 단축키 사용하는 것, 항상 미루면서 학습에 도전하다가 이내 다시 마우스로 돌아가는 패턴이 계속되고 있었다. 단축키는 없어도 사는데 별지장은 없지만, 파워유저 및 개발자로 가는 지름길 중에 하나가 되는 것이다.
실무 코딩을 끊임없이 하자. 나이가 들어가면서 실무코딩을 접고, 관리직으로 가는 사람들도 있는데, 그건 마음만 임요환을 만드는 결과를 초래 할 것이다. HandsOn Modelers(Domain Driven Design, P60)라는 말이 있다. 적은 부분이라도 코딩을 하지 않는 Modelers와 정말 단순하게 도메인 디자인만 하고 빠지는 Modelers는 입맛 살아있는 것인지 진정한 디자인을 할수 없는 것이다, 모델과 디자인은 같이 발전해야 간다. 구현이 바뀌면 모델도 바뀌고, 모델이 바뀌면 구현도 바뀐다.
간혹, 컨설팅을 통해서 개발을 하다가 보면, 초기에 아케텍쳐만 잡고, 간단한 모델링을 하고 빠지는 경우가 많다. 심지어, 처음 만나서 통성명을 하고, 프로젝트 끝까지 볼수 없는 아키텍쳐도 있다. 과연, 처음 만든 그 산출물을 어디까지 효력을 발휘할수 있을까?
정리를 하자면, 얘기는 단순하다
1. 이클립스 단축키를 학습하자.
2. 진정한 architectrue or modeler를 하려면 코딩도 잘해야 하고, 끊임없어 코딩을 해야 한다.
입만 살아 있는 Modelers와 진정한 Modeler!! 여러분은 어디를 선택든지 자유다.
