DDD스터디를 다시 시작했다. 2년만에 다시하는건가?

같은 책을 전에 일부 같이 하던 멤버들과 또 하는 것은 처음있는 일이다.
http://blog.naver.com/jeong_jaehun
http://blog.naver.com/django44

Domain Driven Design을 처음 보는 사람들은 Domain이 뭔지 잘 모르겠다는 얘기를 한다.

우리는 도메인이라는 말을 자주 사용하면서 정작 이 책에 나오는 Domain이라는 말을 파악하기가 쉽지 않다.

어려운 얘기는 하지 않고, 간단히 얘기하면, 특정 분야에 대한 핵심가치가 도메인이라고 생각을 하면 될거 같다.

그 핵심가치게 집중하는 것은 린소프트웨어개발에서 얘기하는 낭비의 제거와 일맥상통한다.

많은 사람들이 DDD이 어렵다고 한다. 사실 DDD가 어려운 건지 그 책이 어려운건지 구별이 잘 안간다. (아마 둘다?)

어렵게 생각하면 끝도 없는 것이 세상일이다. 쉽게 생각을 해보자

DDD의 핵심가치는?
- 도메인에 집중하기
- 낭비 제거하기
- 기본에 충실하기

내가 생각하는 DDD는 이것들을 실행하기 위한 아이디어 또는 설계의 지혜정도가 되겠다.

Posted by ologist
하나의 도메인 영역을 도메인 전문가 모든 이야기를 해주면서 개발자가 분석을 하면 이상적이다.

하지만, 대부분의 거대한 시스템은 하나의 도메인 전문가 아니라 다수의 전문가가 존재한다.

하나의 프로세스를 여러 팀과 사람이 나누어서 협업을 통해서 업무가 진행되기때문이다.

도메인 전문가들은 각자의 영역에서 최고의 지식을 자랑하고 있지만, 다른 영역의 이야기들은 깊게 알지는 못한다.

심지어 업무의 분리에 의해서 각자의 context에서 사용하는 언어들이 미묘하게 틀린 경우를 발견한다.

전체로 볼때는 하나의 일인데, 왜 다른 용어와 생각을 하는 걸까?

나는 여기서 관점이라는 것을 발견했다. 업무에 따라서 관점이 틀리기때문이다.

관점이 여러개로 나누어질때는 하나의 관점으로 통일을 해서 유비쿼터스 랭귀지를 만들어내는 것이 좋다. context마다 변경이 생길수 있는데, 너무 빠르게 진행을 하면 모호함이 생기는 부작용이 생길수 있다.

이미 관례화되고, 변경이 어려운 것들은 무리하게 비꾸려 하지 말고, 각자의 context의 맞게 천천히 변경을 해가자. 중요한 것은 하나의 관점으로 유비쿼터스 랭귀지를 꾸준히 이야기를 해가는 것이다.

Posted by ologist
새로운 모델과 레거시 사이에 translation이 필요할 경우 어디에 둘것인가를 고민하게 된다.

Context 를 넘나드는 슈퍼 모델은 문제가 생길 가능성이 많아 진다.

굵은 글씨는 내가 표시를 해봤다.

A decision was made up front that the new model would depart from that of the legacy, so the legacy cargotracking system is outside the boundary. Necessary translation between the new model and the legacy is to be the responsibility of the legacy maintaince team. The translattion mechanism is not driven by the model. It is not in the BOUNDED CONTEXT. It is good that translation is out of CONTEXT. It would be unrealistic to ask the legacy team to make any real use of the model because their primary work is out of CONTEXT.

- DomainDrivenGesign by Eric Evans

좀더 이 원칙을 확장을 해서 생각을 해보면, 컨텍스트와 레이어가 틀린 경우 클라이언트 모델에 따라서 변환이 필요한 경우가 있다.

이 때 translation을 하는 로직을 어디에 둘지 고민이 많은데, 기본적인 원칙은 모델에 두는 것보다 별도로 translation을 하는 책임을 가지고 있는 것이 좋겠다.
Posted by ologist
모델에 너무 많은 책임을 넣다가 보면, 무거워지고 모델의 특성을 더렵히게 된다.

어떻게 하면 이것을 피할수 있을까? 자연스럽게 관련된 책임을 분리를 해야 한다.

모델의 중요한 비즈니스 로직만 두고, 모델을 잘 보살피기 위한 클래스들을 만들어야 한다.

대부분 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
Posted by ologist
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);
  }


* Fluent Style
  private void makeFluent(Customer customer) {
       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")) );

JMock은 martin fowler가 생각하는 매우 나이스한 fluent API의 모습이다.

Joda Time에서 얘기하는 장점중의 일부를 간추렸다. 3가지를 추렸는데, fluent API의 장점하고 같다.  
  • Easy To use
  • Easy To Extend
  • Good Test Coverage
클라이언트 클래스에 API를 제공할때는 많은 고민을 하게 된다. 항상 적장한 클래스를 만들고 문제를 해결하는 것과 클라이언트 클래스에서 사용하기 쉬운 것에서 선택을 하게 된다.

주로, 사용자 관점에서의 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의 사진을 올려본다.
두 분땜시 참 여러가지로 도움이 많이 된다.

User inserted imageUser inserted image
Posted by ologist
DDD책을 보면서 패러다임이 많이 바뀌었는데, 내가 잘못 이해를 한것이 아닌가 고민스러울때가 있었다.

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님의 말: 목적에 따라서 다양한 모델이 나올 수도 있다는 거고요
[永會] 님의 말: 네.. 목적..



영어가 좀되고, Spring Experience에 참가해서 실시간으로 포스팅을 하는 토비님이 부럽기도 하다. 내년에는 정말 열심히 영어공부를 해서, 빠른 시간이내에 해외 컨퍼런스에 가서 같이 얘기를 하고 싶다.
Posted by ologist
Domain Driven Design

이 책에는 말하는 얘기는 내가 생각했던 Ideal이었다. 이상은 항상 이루기는 쉽지는 않지만, 이루었을때 더더욱 가치가 높은 법이다.

막연히 생각했던 나의 Goal을 철학적으로 잘 풀어준 서적이다.

내가 OOP를 하는 개발자로서 잘못 생각을 했던 개념이나, 놓치고 지나간 부분을 자세하고, 명료하게 적은 책이다.

책 내용 자체가 쉽지않고, 샘플코드가 적어서 이해하기가 더욱 어렵지만, 그런 단점은 많은 상상을 통해서 책을 읽어갈 수 있게 해주기는 한다.

전체적으로 Evans은 무척이나 XP지향 개발자이고, 시종일관 agile스러운 자세로 책을 써내려간다. 중요 개념을 반복적으로 다루면서, 이해를 쉽게 하는 면도 있다.

하나의 Domain Model Pattern(POJOs in Action) 책이기보다는 OOP에 대한 개념을 다시 집대성을 할 정도로 전반적인 내용이 포함되어 있다.  


위에 그림은 Eric Evans가 애기하는 refactoring을 하는 이유이다. refactoring을 하는것보다 새로 만드는 것이 더 빠르게 되기 이전에 소스를 깔끔하게 유지를 하는 습관을 들이는 것이 중요하다.













도움이 되는 사이트를 소개한다.
http://domaindrivendesign.org/

샘플코드도 오픈소스로 올라와 있다.

Posted by ologist
이전버튼 1 이전버튼

블로그 이미지
ologist

공지사항

Yesterday221
Today25
Total34,406

달력

 « |  » 2012.02
      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      

최근에 받은 트랙백

글 보관함