전략적 설계 - DDD. Methodoloy

DDD에 대한 관심은 바람직하지만
빌딩블록에 몰입된 경향에 안타까움을 느낀다.

전체 17개장에서 2.5개 장에 언급된게 전부이고
그나마 패턴으로 익히 전파되고 구현되어온 내용이 빌딩블록이다.
DDD책에서도 빌딩블록을 그다지 중요하게 여기지는 않는다.
  • 설계 혹은 구현 패러다임에 도메인을 구겨넣는 시도를 권장치 않는다.
  • 표준화된 설계요소는 유용한 개념이지만 도메인 설계/모델링에 있어 생산적으로 기여하진 않는다.
  • 패턴에 따른 분할에 집중하기보다 도메인 자체 집중해야 한다.
  • 작은문제에는 유용할 지라도 복잡한 문제를 다루는 데에 있어서는 다른 메커니즘과 원리를 필요로 한다.
빌딩블록은 어디까지나 모델링을 위한 좋은 패턴들로 선택사항일 뿐이다.
도메인주도설계의 모델링이 반드시 빌딩블록을 통해서 이루어져야만 하는 것은 아니다.
그럼에도 빌딩블록과 빌딩블록 구현에 적합한 프레임워크에 관심이 쏠리는 이유는
본인 환경에 최선인 모델링 관례를 정의하기 보다 표준적인요소를 차용하는 것에 익숙하기 때문이라 생각한다.

단지 "express model with 빌딩블록"이고 선택사항일 뿐이다.


적법한 모델링과 분석설계를 상기해 볼 필요가 있다.
  • 규범적인 모델링 규칙을 따르지 않는다.
  • 좋은 설계가 적법한 사용보다 우선되어야 한다.
  • 목적에 맞는 기법을 시도하는 것에 주저말라.
  • 표준적인 기법과 개념이 모든것이 아니라는 것을 깨닫는다.
  • 현재 환경(사용자,기술,도메인)에 적합한 관례를 정의한다.

일반적으로 분석설계에 대해 고민할 때 아래같은 것을 고민한다.
효과적인 협업설계 방법, 개념을 응집하기 위한 분석설계방법과 응집수준,
컨텍스트를 분리하기 위한 방법과 각각을 의미있게 관계를 맺어 중복구현을 떨어트리는 방법,
도메인에 대한 학습비용 그래프(콕번그래프참조)에 따른 효과적인 breakthrough 도래시기 조정방법,
고객이 원하는 요건을 만족시킨다는 것을 증명하기 위한 효과적인 수단과 수준
설계를 구현과 연계하기 위한 수준이나 방법, 구현과정에서 설계를 유지하기 위한 방법과 수준,
구현에서 발생하는 설계비용을 어떤수준으로 유지할것인가에 대한 것, 이들 전부를 포함한 설계전략
DDD책에 물론 이와 관련된 내용들은 담겨있다.
단, 빌딩블록을 지나 2부 마지막부분 부터 끝까지 담겨있다.
내용을 간추리자면 처한 환경에서 효과적인 설계를 하기. 더 간추리자면 전략적 설계.

내가 말하고자 하는 것이 바로 이부분이다
DDD를 적용한다는 의미는 전략적 설계의 실천에 있다는 것
빌딩블록은 자신의 환경에 따라 선택해도 그만 안해도 그만이라는 것.

따분하고 일반적인 얘기로 들리겠지만 DDD의 정수는 뒷부분에 있으니 잘 읽어줬으면 하는 바램이다.


첨언 1, 위의 고민들은 컨텍스트가 딸랑 하나라면 그다지 필요없다.
첨언 2, DDD책 잘 팔렸으면 좋겠다. :)

덧글

댓글 입력 영역