-
소프트웨어는 현실 세계의 비지니스 문제를 해결하기 위해 개발된다. 특정 도메인의 일이 더 잘 되도록 하는 것이 목적이다.
→ 소프트웨어는 도메인의 핵심 개념을 충분히 반영하고 그들 간의 관계를 정확히 실체화 해야한다
-
비지니스의 도메인을 가장 잘 알고 있는 것은 도메인 전문가이다 ex) 은행원, 비행 조종사 등
→ 도메인 전문가들과 긴밀한 협업이 필요
소프트웨어 설계 방식에는 대표적으로 폭포수 방식, 애자일 방법론이 존재하는데 각각 문제가 있다.
-
폭포수 방식: 오버 엔지니어링이 될 가능성, 오버엔지니어링에 대한 우려로 제대로민 설계해야 한다는 강박을 초래할 가능성 등
-
애자일 방법론: 모든 사람의 단순성의 의미에 대한 견해가 제각각일 수 있다 등
→ 도메인 주도 설계가 필요하다
도메인을 중심으로 사고하여 도메인 모델을 설계하는 방식 도메인의 복잡한 문제를 모델링하고 구현할 수 있는 능력을 유지 가능한 방식으로 높여준다 설계와 개발 방식을 연관 지어 설계와 개발이 더 나은 해결책을 도출한다
→ 좋은 설계는 개발을 가속화, 개발 프로세스에서 받는 피드백이 설계를 강화
⇒ 모델은 도메인과 소프트웨어의 교차 지점이다. 소프트웨어 설계자와 도메인 전문가가 이야기를 통해서 지식을 공유하고, 핵심 개념들을 도출하고, 추상화한다. 도메인 모델을 생성한다. (처음 생성한 프로토타입은 완전하지도 않고, 정답도 아니다. 계속해서 수정됨!)
도메인 주도 설계의 핵심 원칙은 모델 기반의 공통 언어(= 유비쿼터스 언어)를 사용하는 것이다. 소프트웨어 아키텍트, 개발자, 도메인 전문가로 구성된 설계팀은 자신의 행동을 통합하고, 모델 작성과 작성된 모델의 코드화를 도와줄 언어가 필요하다.
-
소프트웨어 전문가와 도메인 전문가는 서로 사용하는 언어가 다르고 관점이 다르다
→ 의사소통이 어렵고 모델이 중요한 표현들을 정확히 담기 어렵다
→ 도메인 모델을 이야기하고 정의할 때 공통의 언어가 필요하다 = 유비쿼터스 언어!
→ 도메인과 설계를 정의할 핵심 개념을 찾아 그에 해당하는 적절한 단어를 찾고 사용하라. 명확한 결과를 도출할 수 있는 언어를 만들어야 한다
소프트웨어 전문가와 도메인 전문가가 대화를 통해 도메인의 중요한 핵심 개념을 찾고 주요 단어들을 이용해서 점진적으로 초기 모델을 만든다.
그 과정에서 도메인 전문가는 어색하거나 오해를 일으키는 용어 및 구조에 반대한다. 도메인 전문가가 모델이나 언어의 어떤 부분을 이해할 수 없다면 그 부분은 잘못되었을 확률이 매우 높다.
개발자는 설계에서 나타날 수 있는 모호함이나 불일치를 늘 검토한다. 모델의 주요 개념을 코드로 구현해보는 것도 추천한다. 모델 개념을 그에 대응하는 클래스, 메서드, 모듈, 코드에 적용해봄으로서 모델과 코드, 언어와 코드를 매핑해나간다. 그를 통해 코드 가독성이 높아지고 모델을 재구성하기도 유용해진다.
계속해서 가장 적절한 언어로 수정해나간다.
유비쿼터스 언어는 모델에 대한 지식을 공유하고 이해하는 토론에서 사용되고, 다이어그램, 문서를 작성할 때도 사용한다.
-
UML
- 핵심 개념을 클래스로 표현하고 그 클래스의 관계를 표현하는데 좋은 도구
- 같은 비전을 즉시 공유할 수 있고, 의사소통이 쉽고, 수정하기 쉽다
- 관련 요소가 많아지면 전체 UML을 만들기도 어렵고 만들더라도 이해하기도 어렵다
- 클래스와 내부 속성 및 그 사이 관계를 표현하기는 적합하지만, 클래스의 행동이나 제약 사항을 표현하기 쉽지 않다
→ UML을 중요한 부분 부분으로 나누어 작성하고, 필요한 부분에 문서(텍스트)를 이용할 것!
→ 이 텍스트에 유비쿼터스 언어가 사용된다.
모델은 어느 정도 안정된 상태에 도달하기 전까지 계속 바뀌기 마련이다. 완벽하고 거대한 다이어그램, 문서 만드는 것을 주의하라. 문서는 모델과 동일한 내용을 반영할 수 있어야한다. 코드로 의사소통하는 것도 추천!(하지만 모델의 코드화는 쉽지 않다)