DDD스터디를 다시 시작했다. 2년만에 다시하는건가?
같은 책을 전에 일부 같이 하던 멤버들과 또 하는 것은 처음있는 일이다.
http://blog.naver.com/jeong_jaehun
http://blog.naver.com/django44
Domain Driven Design을 처음 보는 사람들은 Domain이 뭔지 잘 모르겠다는 얘기를 한다.
우리는 도메인이라는 말을 자주 사용하면서 정작 이 책에 나오는 Domain이라는 말을 파악하기가 쉽지 않다.
어려운 얘기는 하지 않고, 간단히 얘기하면, 특정 분야에 대한 핵심가치가 도메인이라고 생각을 하면 될거 같다.
그 핵심가치게 집중하는 것은 린소프트웨어개발에서 얘기하는 낭비의 제거와 일맥상통한다.
많은 사람들이 DDD이 어렵다고 한다. 사실 DDD가 어려운 건지 그 책이 어려운건지 구별이 잘 안간다. (아마 둘다?)
어렵게 생각하면 끝도 없는 것이 세상일이다. 쉽게 생각을 해보자
DDD의 핵심가치는?
- 도메인에 집중하기
- 낭비 제거하기
- 기본에 충실하기
내가 생각하는 DDD는 이것들을 실행하기 위한 아이디어 또는 설계의 지혜정도가 되겠다.
'DDD'에 해당되는 글 17건
- 2008/03/09 도메인 영역에 집중하기 (10)
- 2008/03/09 유비쿼터스 랭귀지를 만들때 (11)
- 2008/01/15 도메인 모델을 더럽히지 않으려면 (9)
- 2007/04/07 이제 Domain Model에 Dependency Injection을 하자 (6)
- 2006/12/28 Eric Evans의 인터뷰 글 (12)
- 2006/12/10 Normal vs Fluent interface (7)
- 2006/12/09 국내에 DDD 전도사 이야기들 (11)
- 2006/12/09 Domain Driven Design with Eric Evans (9)
- 2006/10/13 eclipse(이클립스) 단축기와 실무 (17)
- 2006/10/11 Domain Driven Design - Eric Evans (11)
하지만, 대부분의 거대한 시스템은 하나의 도메인 전문가 아니라 다수의 전문가가 존재한다.
하나의 프로세스를 여러 팀과 사람이 나누어서 협업을 통해서 업무가 진행되기때문이다.
도메인 전문가들은 각자의 영역에서 최고의 지식을 자랑하고 있지만, 다른 영역의 이야기들은 깊게 알지는 못한다.
심지어 업무의 분리에 의해서 각자의 context에서 사용하는 언어들이 미묘하게 틀린 경우를 발견한다.
전체로 볼때는 하나의 일인데, 왜 다른 용어와 생각을 하는 걸까?
나는 여기서 관점이라는 것을 발견했다. 업무에 따라서 관점이 틀리기때문이다.
관점이 여러개로 나누어질때는 하나의 관점으로 통일을 해서 유비쿼터스 랭귀지를 만들어내는 것이 좋다. context마다 변경이 생길수 있는데, 너무 빠르게 진행을 하면 모호함이 생기는 부작용이 생길수 있다.
이미 관례화되고, 변경이 어려운 것들은 무리하게 비꾸려 하지 말고, 각자의 context의 맞게 천천히 변경을 해가자. 중요한 것은 하나의 관점으로 유비쿼터스 랭귀지를 꾸준히 이야기를 해가는 것이다.
어떻게 하면 이것을 피할수 있을까? 자연스럽게 관련된 책임을 분리를 해야 한다.
모델의 중요한 비즈니스 로직만 두고, 모델을 잘 보살피기 위한 클래스들을 만들어야 한다.
대부분 presentation layer와 persistence layer에서 문제가 생긴다. 이것을 해결해보자,
1. 웹,DB에서 입력값이 있는 경우 모델에 올바르게(wellformed)하게 데이터를 넣어주는 role을 가진 로직이 존재해야 한다.
2. 웹, DB에 데이터를 보여주거나 넣을 때 입력받은 값 그대로 넣지 않고, decorate가 필요한 경우가 있다. decorate하는 로직이 존재해야 한다.
1,2번의 로직은 경우에 따라서 구현하는 위치가 틀려 질수가 있다. 간단한 구현체나 하나의 클래스에 로직을 추가해도 되지만, 추가하려는 로직이 일관성을 어기거나 모델을 손상시키는 경우 과감하게 떼어내자.
A model applies in a context. The context may be a certain part of the code, or the work of a paticular team.
- DomainDrivenDesign by Eric Evans
- DomainDrivenDesign by Eric Evans
그날로 바로 관심있던 deendency한 라이브러리(spring-aspects.jar)도 추가로 maven pom.xml에 추가를 하고 몇 가지를 테스트를 해봤다.
The spring-aspects.jar
contains an annotation-driven aspect that exploits this capability to allow dependency-injection
of any object
spring-aspects는 annotation기반으로 depdency injection이 가능하다.
spring2.0에서 aspect를 이용해서 domain model에 dependency injection을 하는 방법
http://www.springframework.org/docs/reference/aop.html
Using AspectJ Load-time weaving (LTW) with Spring applications
http://www.springframework.org/docs/reference/aop.html#aop-aj-ltw
<!DOCTYPE aspectj PUBLIC
"-//AspectJ//DTD//EN"
"http://www.eclipse.org/aspectj/dtd/aspectj.dtd">
<aspectj>
<weaver
options="-showWeaveInfo
-XmessageHandlerClass:org.springframework.aop.aspectj.AspectJWeaverMessageHandler">
<include within="com.xyz.myapp..*"/>
</weaver>
</aspectj>
weaving되는 package를 결정을 할수가 있다. /META-INF/aop.xml에 정의를 해서 사용을 하면 된다
A Practical Guide to Using an Aspect Library (part I)
http://www.aspectprogrammer.org/blogs/adrian/2006/02/a_practical_gui_2.html
prototype or singleton?
AOP@Work: Dependency injection with AspectJ and Spring
http://www-128.ibm.com/developerworks/java/library/j-aopwork13.html
Spring, DDD and AspectJ - An Example
http://ryanbreidenbach.blogspot.com/2006/09/spring-ddd-and-aspectj-example.html
덧글이 흥미롭네요. 좋은 예제는 아닌듯...OTL
Configurable API
http://www.springframework.org/docs/api/org/springframework/beans/factory/annotation/Configurable.html
Spring 2.0 AOP - Spruce Up Your Domain Model
http://www.ologist.co.kr/308
예전에 spring2.0 new feature가 나올때 정리한 것
열심히 코드짜고 테스트를 해보다가, weaving에 일단 무릎 꿇다...^^;
runtime시 이 파라미터를 모두 추가하는 것은 지금 일단 시기가 적절치 않다. 그 밖에 품질을 위해서 신경을 써야 할게 더 많다. 일단, 명시적인 코드상의 DI를 하도록 해야겠다.
weaving rumtime VM parameter
-javaagent:lib/aspectjweaver.jar
Eric Evans의 인터뷰 글
http://www.infoq.com/articles/eric-evans-ddd-matters-today
가장 인기있는 OOP언어들이 나열되어 있고, agile이라는 단어가 들어가 있다. Eriv Evans가 책에서 하는 이야기들은 조금은 예상할 수 있는 단어들이다.(아마 infoQ에서 설정한 카테고리인듯 하다.)
인터뷰 내용을 몇 가지만 살펴보자
plain old java objects (POJOs) can still be made readable. And some of the Java 5 syntax innovations help readability.
자바 코드에 대한 가독성에 대한 이야기도 있다.
infoQ : Do you have any advice for people trying to learn DDD today?
EE : Read my book! ;-)
EE : Read my book! ;-)
흠...센스있는것인가...ㅎㅎㅎ
책을 보도록 유도를 하는데, 한번 봐주자.
마지막에 Eric Evans소개를 할때 Domain Language라는 말이 나온다. 어떤 식의 코드를 만들어내야 더 나은 소통을 할수 있을까? 코드로 이한 오해가 없어지는 모습을 만드는 방법은? 어떻게 하면 좀더 나은 랭귀지를 디자인할수 있을까?
Normal vs Fluent interface
* Normal Style
private void makeNormal(Customer customer) {
Order o1 = new Order();
customer.addOrder(o1);
OrderLine line1 = new OrderLine(6, Product.find("TAL"));
o1.addLine(line1);
OrderLine line2 = new OrderLine(5, Product.find("HPK"));
o1.addLine(line2);
OrderLine line3 = new OrderLine(3, Product.find("LGV"));
o1.addLine(line3);
line2.setSkippable(true);
o1.setRush(true);
}
Order o1 = new Order();
customer.addOrder(o1);
OrderLine line1 = new OrderLine(6, Product.find("TAL"));
o1.addLine(line1);
OrderLine line2 = new OrderLine(5, Product.find("HPK"));
o1.addLine(line2);
OrderLine line3 = new OrderLine(3, Product.find("LGV"));
o1.addLine(line3);
line2.setSkippable(true);
o1.setRush(true);
}
* Fluent Style
private void makeFluent(Customer customer) {
customer.newOrder()
.with(6, "TAL")
.with(5, "HPK").skippable()
.with(3, "LGV")
.priorityRush();
}
customer.newOrder()
.with(6, "TAL")
.with(5, "HPK").skippable()
.with(3, "LGV")
.priorityRush();
}
오늘은 DDD에 대한 소식을 듣고, 예전에 봤던 글들을 다시 한번 봤다. 또, 느낌이 틀리다.
전에 봤던 그 느낌하고, 지금 느낌은 또 틀리다. 이 글을 또 나중에 한번 더 봐야겠다.
JMock's contains a very nice fluent API
mock.expects(once()).method("m").with( or(stringContains("hello"),
stringContains("howdy")) );
stringContains("howdy")) );
JMock은 martin fowler가 생각하는 매우 나이스한 fluent API의 모습이다.
Joda Time에서 얘기하는 장점중의 일부를 간추렸다. 3가지를 추렸는데, fluent API의 장점하고 같다.
- Easy To use
- Easy To Extend
- Good Test Coverage
주로, 사용자 관점에서의 API는 좀더 편하게 사용할수 있는 인터페이스가 더 좋은 API라는 생각을 한다. 그런 관점에서는 fluent API들은 너무도 직관적이고, 이해하기가 쉽다.
DomainSpecificLanguage
http://www.martinfowler.com/bliki/DomainSpecificLanguage.html
DslBoundary
http://www.martinfowler.com/bliki/DslBoundary.html
Generating Code for DSLs
http://www.martinfowler.com/articles/codeGenDsl.html
EvansClassification
http://www.martinfowler.com/bliki/EvansClassification.html
FluentInterface
http://www.martinfowler.com/bliki/FluentInterface.html
TimeAndMoney Java Code Library
http://timeandmoney.domainlanguage.com/
Joda Time - Java date and time API
http://joda-time.sourceforge.net/
March is Not a Number
http://www.eaipatterns.com/ramblings/40_marchnan.html
EDSL
http://altlang.org/fest/%EC%96%B8%EC%96%B4%EC%86%8D%EC%96%B8%EC%96%B4
오늘은 김창준님이 대안언어축제했던 발표문서를 보다가 정말 여러가지 건졌다.
아주 재미있는 글들이 많았다.
요즘 한창 잘나가는 eric evans와 우리의 영원한 영웅 martin fowler의 사진을 올려본다.
두 분땜시 참 여러가지로 도움이 많이 된다.
 |  |
spring2.0 overview를 통해서 DDD를 나에게 알려주었던 국내에 DDD전도사 토비님이 이번에는 The Spring Experience2006까지 가셔서 많은 정보들을 블로그에 포스팅을 하고 있습니다.
토비님 블로그에서 다음과 같은 정리는 내가 제대로 이해는 했다는 생각을 갖게 했다.
당연한 이야기지만, 어떤식으로 엔트리 포인트를 정할 것인가? 관계를 어떻게 가져가야 정말 우리가 원하는 Rich한 모델을 만들수가 있는가? 개발을 하다가 보면 고민이 많다.
사실, 개발하면서 처음 생각한 디자인하고, 계속 달라지는 느낌도 많이 받았다. 물론, 개발자와 domain expert와 대화를 하면서, 풀어나간 Eriv Evans의 이야기들처럼 누군가의 대화는 아니었지만, 나 자신이 하면서 좀더 스키마가 생기면서 바뀌는 코드들의 느낌이라고 할수 있다.
The Spring Experience 둘째날
http://toby.epril.com/?p=253
또 한가지 강조한 것은 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님의 말: 목적에 따라서 다양한 모델이 나올 수도 있다는 거고요
[永會] 님의 말: 네.. 목적..
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 우리가 많이 사용하던 단어이지만, 다시 한번 의미를 되새겨 볼만한 충분한 가치가 있을 것이다.
Eric's Favorite Modeling Tools (currently available)
- 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.
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.
An Introduction to Domain-Driven Design
http://www.thespringexperience.com/speaker_topic_view.jsp?topicId=258
[TSE] Domain Driven Design with Eric Evans
http://raibledesigns.com/page/rd?entry=tse_domain_driven_design_with
Eric Evans
|
|
1998년 군제대를 하고나서, 의지를 가지고 처음 배운 일은 스타크래프트 게임이었다.
처음에 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!! 여러분은 어디를 선택든지 자유다.
이 책에는 말하는 얘기는 내가 생각했던 Ideal이었다. 이상은 항상 이루기는 쉽지는 않지만, 이루었을때 더더욱 가치가 높은 법이다.
막연히 생각했던 나의 Goal을 철학적으로 잘 풀어준 서적이다.
내가 OOP를 하는 개발자로서 잘못 생각을 했던 개념이나, 놓치고 지나간 부분을 자세하고, 명료하게 적은 책이다.
책 내용 자체가 쉽지않고, 샘플코드가 적어서 이해하기가 더욱 어렵지만, 그런 단점은 많은 상상을 통해서 책을 읽어갈 수 있게 해주기는 한다.
전체적으로 Evans은 무척이나 XP지향 개발자이고, 시종일관 agile스러운 자세로 책을 써내려간다. 중요 개념을 반복적으로 다루면서, 이해를 쉽게 하는 면도 있다.
하나의 Domain Model Pattern(POJOs in Action) 책이기보다는 OOP에 대한 개념을 다시 집대성을 할 정도로 전반적인 내용이 포함되어 있다.
위에 그림은 Eric Evans가 애기하는 refactoring을 하는 이유이다. refactoring을 하는것보다 새로 만드는 것이 더 빠르게 되기 이전에 소스를 깔끔하게 유지를 하는 습관을 들이는 것이 중요하다.
도움이 되는 사이트를 소개한다.
http://domaindrivendesign.org/
샘플코드도 오픈소스로 올라와 있다.
