에릭에반스 - DDD 책을 읽고 내생각을 첨가해서 짜집기한 글
동작하는 도메인 모델 만들기
모델은 중요한 사실이나 사상의 일부 측면을 추상화하여 대상을 단순화한 것이다.
어떠한 사실을 해석한 것으로도 볼 수 있고, 문제해결과 관련된 측면을 추상화하고 그 밖의 세부사항에는 주의를 기울이지 않는다.
(모델링을 할 때 아직 세부사항은 필요가 없다. 사람의 움직임을 그림으로 그린다고 생각해보자
뼈, 근육, 피부조직, 혈관, 혈액 등의 움직임이 필요한가?)
대개 소프트웨어 도메인은 몇 가지 예외적인 경우를 제외하면 컴퓨터와 거의 관련이 없다.
소프트웨어 개발 자체가 도메인이 되는 소스 코드 관리 시스템같이 말이다.
도메인 모델은 단지 도메인 전문가의 머릿속에만 존재하는 지식이 아니라 해당 지식을 엄격하게
구성하고 선택적으로 추상화한 것이다.
책에서는 도메인 모델러를 자신의 경험을 토대로 특유의 방식으로 이야기하고 논지를 펼쳐 나가는 영화 제작자와 비유를 했다.
모델의 유용성에 따라 특정 모델을 선택하기 때문이다.
도메인 주도 설계에서의 모델의 유용성
모델과 핵심 설계는 서로 영향을 주며 구체화된다.- 모델을 이해한 바로 코드를 해석할 수 있다.
모델은 모든 팀 구성원이 사용하는 언어의 중추다.- 모두 같은 언어를 사용한다면 도메인 전문가와의 의사소통에서 별도의 번역이 필요하지 않다.
모델은 지식의 정수만을 뽑아낸 것이다.- 모델에는 우리가 용어를 선택하고, 개념을 분류하며, 분류한 지식을 서로 연관시키 때 도메인에 관한 우리의 사고방식이 담겨 있다.
소프트웨어의 본질
소프트웨어의 본질은 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다.
개발자는 그 문제를 해결하는 전문가다.
개발자는 업무 지식을 증진하기 위해 도메인 연구에 몰두해야 한다. 그뿐만 아니라 모델링 기법을 연마해서 도메인 설계에 통달해야한다.
기술적인 부분에만 너무 몰두한다면 정작 문제 해결보다 기술을 우선시하게 되어 본질과는 전혀 다른 결과를 만들 수 있기 때문이다.
익숙하지 않은 도메인과 복잡성을 두려워하지 않는다면 훨씬 더 가치 있는 개발자가 될 수 있는 성장의 밑거름이 될 것이다.
지식탐구
개발자는 도메인 전문가에게 도메인 지식을 배우고 그의 말 속 본질적인 문제영역을 탐색하여 모델링을 해야한다.
현재 나의 도메인 지식이 맞는지, 설계가 맞는지 도메인 전문가와 계속 확인 해야한다.
이때 개발자의 언어와 도메인 전문가의 언어를 통합한다면 더욱 원할한 소통이 가능하다.
개발자와 도메인 전문가는 서로에게 배우는 자세로 임해야한다.
효과적인 모델링의 요소
성공적인 모델링을 위한 활동
모델과 구현의 연계- 초기 모델을 토대로 본질적인 연결 고리를 이어지는 반복주기 내내 유지
모델을 기반으로 하는 언어 정제- 이해관계자간 언어의 규약을 설정 (수신호, 봉화 같이)
풍부한 지식이 담긴 모델 개발- 객체는 행위를 지니고 규칙을 이행한다.
- 모델은 데이터 스키마가 아니라 다양한 지식을 포함하여 복잡한 문제를 해결한다.
모델의 정제- 본질에 집중하여 필요하지 않거나 중요하지 않은 개념은 제거한다.
- 변경을 두려워하지마라
브레인스토밍과 실험- 토의 중 나온 아이디어를 지속적으로 다양한 가능성을 연습,실험,평가
- 풍부한 지식이 담긴 모델을 발견, 정제하기 위해선 지속적인 브레인스토밍과 수차례의 실험으로 얻은 창의성이 필요하다.
지식 탐구
지식 탐구는 도메인 전문가와 개발자가 서로 협업하여 도메인을 도출하는 과정이다.
이 과정에서 수많은 모델을 시도,거부,변형하여 모든 세부사항에 들어 맞는 추상적 개념이 나타나면 비로소 성공에 이른다.
해당 모델의 원재료는 도메인 전문가의 머릿속이나 기존 시스템 사용자, 비슷한 도메인의 기술팀 혹은 이전의 다른 프로젝트에서 얻은 경험에서 나온다.
지식의 축적
과거의 폭포수 개발 방식의 경우
업무 전문가 -> 분석가 -> 프로그래머 에게 지식이 흐르는데
이러한 방법은 피드백이 잘 이루어질 수 없어 지식이 한 방향으로만 조금씩 흐르고 축적되지 않는다.
또한 업무 내용은 전달되는 과정에서 전달되어야하는 내용이 누락될 가능성도 크고 해결해야할 문제 영역을 잘못 이해할 수 있다.
반면 애자일하게 일하지만 추상화를 하지 않아 지식의 축적이 실패하기도 한다.
모델의 발전
프로그래머가 지속적으로 리팩터링하며 개발한다면 소프트웨어는 말끔한 상태로 유지되겠지만
도메인에 관심이 없다면 본질을 알지 못한 채 애플리케이션에서 수행해야 할 사항만 습득한다.
모든 구성원이 함께 모델을 면밀히 만들어 나가 상호작용한다면
도메인 모델의 지속적인 정제를 토대로 개발자는 기능만 기계적으로 만드는 데 머무르지 않고 자신이 보조하고 있는 업무의 중요 원칙들을 배울 수 있다.
도메인 지식을 기반으로 추상화를 진행해라 그렇지않고 기술적인 측면에서만 접근한다면 개념은 초보적인 수준에 머무를 것이다.
도메인 전문가의 지속적인 관여로 모델은 심층적인 업무 지식을 반영하고, 추상화된 개념은 참된 업무 원칙에 해당한다.
이렇게 만들어진 모델은 도메인을 이해하는 데 실용적이고 유용하며 쉽게 구현하고 이해하기에 충분할 만큼 엄밀해야 한다.
지속적인 학습
소프트웨어를 작성하기 시작할 때 우리는 충분히 알지 못한 상태에서 시작한다.
이런 상태에서 스스로 얼마나 알지 못하는가를 깨닫지 못한다면 무지로 인해 잘못된 가정을 하게된다.
전형적인 설계 방법으로는 코드와 문서에서 유용한 형태로 표현되지 못한 지식이 어떠한 이유로든 구두로 전달하기 어려워지면 지식은 사라지게 된다.
생산성이 매우 뛰어난 팀은 지속적인 학습을 바탕으로 의식적으로 지식을 함양한다.
핵심 팀원에게 축적된 지식으로 그들은 더욱 유능한 지식 탐구자가 된다.
이 다음 작업은 팀 구성원, 도메인 전문가 모두 똑같은 지식을 얻고 의사소통 체계를 공유하며, 구현을 거쳐 피드백 고리를 완성하는 일을 효과적으로 수행하는 작업을 지식 탐구 프로세스라는 작업으로 프로세스화 하는 것이다.
풍부한 지식이 담긴 설계
도메인의 업무 활동과 규칙도 도메인에 중요하다.
도메인마다 전문적인 용어가 있을탠데 이 용어의 뜻을 제대로 이해하는 통찰력을 모델에 반영해야한다.
업무 규칙을 차례로 확인하여 비거나 모순되는 사항을 명확하게 하고, 구체화하며, 조정하거나, 고려해야 할 범위 밖으로 배제하는 것은 소프트웨어 전문가와의 긴밀한 협업하에서 진행되는 지식 탐구를 통해 이뤄진다.
이러한 사항으로는 업계의 관행 같은게 있을 수 있다.
(도메인 전문가에게는 너무 당연해서 말하는걸 놓칠 수 있기 때문)
정제 과정을 거쳐 중요한 것에 집중하고 나머지는 축소, 분리하여 더 명시적으로 만들어야 한다.
심층 모델
유용한 모델은 겉으로 드러나 있는 경우가 거의 없다.
우리는 요구사항을 더 잘 이해하게 되면서 대체로 처음에 중요하게 생각했던 모델 요소를 버리거나 관점을 바꾼다.
이로써 처음에는 나타나기 힘들지만 문제의 핵심을 관통하는 포착하기 힘든 추상화가 서서히 나타나기 시작한다.
심층 모델을 유용하고 명확하게 만들려면 도메인은 물론 모델링 기법도 정교한 솜씨가 필요하다.
심층 모델이라 생각했지만 도메인 전문가가 만족스러워하지 않는다면 우리는 도메인 전문가가 업무를 바라보는 방식을 놓쳤기 때문이다.
지식 탐구는 탐험과도 같아 어디서 끝날지 아무도 알지 못한다.
