Domain Driven Design.

DDD는 언급하기 참 꺼려지는 주제다.
이유는 블로그가 개인적인 메모용도이기도 하지만
그래도 이론에 치중된 이빨까기로 보여지는게 의식되는 부분도 없지않아 있기 때문이다.
그럼에도 불구하고 DDD는 object design, organizational patterns와
더불어 개인적으로 생각날때마다 뒤적이는 명서이기에 언급을 하고 싶어 조금 긁적여 본다.


1. DDD 설명.
Domain Model이란 사실을 단순화시킨 해석의 하나로
관련자가 모델을 통해 목적에 부합되는 가치를 발견하고 획득할 수 있도록
의도적인 강조와 단순화를 통한 추상화로 문제(사용자에게 가치있는 소프트웨어 만들기)에
효과적으로 집중할 수 있게하는 것. 이것이 바로 DDD다.

이러한 목적을 위해 Domain에 충실한
소통되는 Model을 만드는 것이 중요한데
DDD에서는 이를 위해 Layered architecture에서 Domain Layer에
도메인 모델을 격리시키는 방법과 모델주도설계방법을 강조하면서
복잡도와 결합성, 응집성을 해결하기 위한 partitioning원리를 알려준다.

이런 과정으로 훌륭한 Domain Model을 만들었음에도 불구하고
도메인 핵심을 관통하는 예리하고도 통찰력있는 모델은 단번에 만들어질 수 없다.
따라서 모델은 발전과정에도 견고함을 유지할 수 있는 유연함이 필요하며
핵심을 발견해내기 위한 전략과 아이디어 차용을 위해 패턴을 사용하는 지혜도 중요하다.

도메인이 단일모델로 다루기 힘든 복잡도나 규모를 가진 경우
DDD에서는 인식, 통찰과 책임의 범위를 context란 단위로 해결안을 제시하는데
이러한 context들을 프로젝트관리나 소프트웨어관점에서 통찰하고
전략적으로 드라이브해야할 필요성을 설명하며 몇가지 패턴을 얘기해주고 있다.
그리고 도메인들에게서 가치의 핵심을 뽑아내기 위한 전략적인 과정을 설명하고
대규모를 다루기 위한 패턴과 조언들을 포함하고 있다.


2. DDD 구현은 어떻게?
업계에서 주목되는 부분은 구현레벨의 마이크로패턴이고
DDD도 마찬가지로 building block지원 인프라에 대한 관심이 지대하다.
building block은 어디까지나 효과적인 패턴으로써 제안되는 부분인데
이러한 제안된 practice에 너무 매달리는 것은 좋지않다고 말하고 싶다.
Evans도 builidng block이 지나치게 강조된 것을 언급한 바 있다.(DDD포럼이나 발표영상)

즉, DDD에서 표현력이 풍부한 모델을 만드는 원리가 중심이면
building block과 관련된 패턴은 당사자가 환경이나 입장에서 선택, 확장가능한 부분이란 얘기다.
실제로 Domain Events, Big Ball of Mud가 추가되었고 앞으로도 많은 패턴들이 차용될 것이다.

- 기존 아키텍처나 프레임워크를 유지하고 Domain Layer를 격리하고
  아키텍처 미학을 위한 Layer추가를 통제하는 정도로 그치는 것도 좋은 방법이다.
- infra와 연결되는 respository부분에서 domain object에 대한 프레임워크수준의 해결책도 좋다.
- B-level SOA / infra로 구분해서 도메인레이어를 서비스로 올려버리는 것도 좋다.(내취향)

즉, Evans가 인정한 방법을 얼마나 사용하고있느냐 

혹은 그것이 DDD인지를 판단하는 기준이 중요한 것이 아니라
자신이 확신하고 선택할 수 있는 좋은방법을 DDD에서 차용했다면 그것으로 족하다.
억지로 building block으로 모델과 구현, 인프라에 속박되지 말라고 당부하고 싶다.
(경영 > 전략 > 상품 > 운영 4가지 혁신 중에서 practice 무차별 적용은
(단기적인 하책인 운영환경 개선책중에서 환경을 고려치않은 하책이 될 수도 있다.

Sticking with MODEL-DRIVEN DESIGN When Mixing Paradigms을 인용하여 하고싶은 말을 대신한다.

- Don't fight the implementation paradigm
  There's always another way to think about a domain.
  Find model concepts that fit the paradigm

3. 구체적으로 DDD를 어떻게 유용하게 사용하란 얘기?
DDD를 설계용으로 국한시켜 볼 수도 있는데 그보다 널리 사용할 수 있다.

프로젝트관리, 방법론, 분석설계 원리, 조직, 전략적 의사결정에 널리 참고가능한 내용이다.

뻔한 얘기이지만 그러한 뻔함에 대해 얼마나 주의를 기울이는가가 성공과 실패를 가른다.

처음부터 끝까지 통찰했다면 진심으로 1개월간 수백쥐어가며 선생으로 모시고 싶은 생각도 있다.

구현관점에서 코드는 어디에..? 

이론적 내용이네 빛좋은 개살구네? 이렇게 생각하면 얻을게 하나없다.

이 내용들은 속칭 관리자나 속칭 이빨까는 사람들을 위한 이론이 아니라
개발자를 포함해 쓰여진 실천서이다. 부디 멀리하지 말고 반복적으로 읽었으면 하는 바램..



[생각할 것들]
- 마이크로패턴에서 비롯된 바람직한 아키텍처나 프레임워크는
  편의성이나 시스템에서 의도를 부각시켜주는 것을 비롯해 비즈니스에 이르기까지 많은 혜택을 부여해준다.
  그러나 DDD에서 가치의 핵심은 코어도메인의 비즈니스패턴이란 점을 자주 상기해봐야 한다.
  그럼에도 불구하고 비즈니스 가치를 획득하기 위한 분석설계, 방법론, 프로젝트관리, 조직체계에 대한 관심은
  시간이 지날수록 퇴행하는 듯한 모습을 보이는데 업계전체적으로 해당 가치가 과소평가되는것 같아 아쉽다..
- bind model and implementation을
  혹자는 implementation model과 design model의
  round-trip engineering, synchronization으로 오해하는데 그와같은 접근이 아니다.
  설계와 구현은 일치하지 않는다. 둘을 synch 맞춰서 무슨 가치를 얻을 수 있겠는가..
  구현된 코드가 모델과 100%일치하는 경우와 의도를 준수하는 것의 가치차이를 생각해보길 바란다.
  jit design, emergent design이란 말이 존재하는 이유는 의도와 구현간 가치차이를 인정하기 때문이다.

  (어디선가 이와같은 식으로 접근한 sdlc이미지를 보았는데 마음에 들진 않는다.
- 모델링 기법이 무엇이든 상관없지만 외형을 사진찍듯하는 분석설계나 모델링은 무가치하다.
- Domain에 집중할 관심사가 추가된 layer에 분산되는 경향은 늘 고려해야 한다.
- 너무나 당연한 얘기들이라고 흘리게 되는 부분이 많아서 한가지 예를들어보겠다.
  RC Martin이 system boundary diagram을 강조하던 시절(내용구성상)에
  발생한 차세대프로젝트에서도 system boundary diagram이 뻘쭘하니 나온 경우가 있다.
  package를 x으로 보는것. 이게 설계를 망치는 대표적인 케이스다.
  뭔소리냐면 빨강,노랑,파랑색이 a4용지에 펼쳐져있는데 녹색이 어떻게 구성되는 지에 관심있다.
  복잡도를 컨트롤하려면 어떻게 해야하나? 녹색을 사각형으로 박스치면 되서 그것만 들여다보면 될까?
  DDD를 100번 읽어도 Module이군..하고 지나치면 얻을게 없다. Module 다시 읽어보길..