DDDQ 1장 도메인 주도 설계란 무엇인가?
DDDQ(Domain Driven Design Quickly) - 도메인 주도 설계란 무엇인가? 라는 책의 간단 요약 정리
소프트웨어 개발이 어려운 이유는 현실세계 문제의 복잡성에서 시작된다
도메인
- 자동화된 비즈니스 프로세스
- 현실세계의 문제
- 하나의 도메인은 세상의 어떤 것
- 그래서 복잡함 - 본질적 복잡성
본질적(필연적) 복잡성 : 소프트웨어 구현하고자 하는 기능에 대한 복잡성
우연적 복잡성 : 소프트웨어를 구현하는 행위(언어, 툴, 라이브러리 등)에 따른 복잡성
도메인 모델
- 소프트웨어 기능을 위해서 도메인 전문가의 지식에서 선택적으로 추상화하여 엄격하게 조직화한 것
- 다이어그램 등으로 전달하고자하는 아이디어
- 다이어그램이나 그림은 모델을 가시적으로 표현하고 전달하는 역할일 뿐
- 복잡성을 다루는 도구이자 추상화의 결과
- 도메인 전문가와 개발자(개발자들 간에도) 사이의 소통의 중심
- 지속적인 피드백이 가능하고 최신상태를 유지해야 의미가 있다.
- 기능(요구사항) - 도메인 모델(유연한 설계) - 구현이 자연스럽게 연결. 즉, 기능과 구현의 자연스로운 통로
- 소프트웨어 구현에 자연스럽게 녹아들어야 한다.
도메인 전문가 : 현실세계의 문제(업무)를 가장 잘 이해하는 해당분야 전문가 (ex:은행원, 항공관제사 등)
개발자 : 설계자, 개발자 등 소프트웨어를 구축하는 이
소프트웨어
- 소프트웨어는 도메인의 핵심개념과 각 구성요소를 담고 있어야 하고 그들 간의 관계를 정확하게 실체화해야 한다.
- 소프트웨어는 도메인을 모델링해야 한다
(도메인 모델을 통한) 좋은 설계는 개발을 가속화 하고, 동시에 개발 프로세스에서 받는 피드백이 설계를 강화한다.
도메인 지식 쌓기
일반화(Generalization)
- 추상화의 한 기법
- 공통적인 부분을 골라내는 것
개념 (Concept)
- Type
도메인에 대한 개발자의 분석적인 자세는 도메인 전문가들과 토의하는 도중에 도메인의 핵심 개념(Concept) 을 발굴해 내는데 도움이 된다.
개발자와 도메인 전문가들은 도메인 모델을 함께 만들어 낸다.
도메인과 소프트웨어는 도메인 모델을 통해서 철저하게 혼합되어야 한다.
유비쿼터스 언어
공통 언어의 필요성
공통 언어가 없다면?
- 각 전문 분야 용어와 서로 다른 언어에 따른 의사소통이 어려움
- 번역 비용
- 예를 들어 개발자는 A 라는 용어를 쓰는데 도메인 전문가는 이해가 안되므로 도메인 전문가에게 설명을 위한 다른 용어로 표현
- 번역 자체 비용 뿐만 아니라 용어의 혼재까지 발생해서 복잡도가 상승함
- 자신만의 방언
솔루션
- 도메인 모델 기반 언어 : 모델을 표현할 때 사용하는 용어
- 다이어그램에 적혀진 언어를 프로젝트 의사소통 시에도 소리내어 사용
- 이 언어를 유비쿼터스 언어(보편 언어) 라 부른다.
만약 해당 언어나 모델을 도메인 전문가가 잘 이해하지 못하면 그 부분은 잘못되어 있을 가능성이 매우 높다.
유비쿼터스 언어 만들기
항공기 관제 예제의 용어와 핵심개념
- 비행기, 출발지, 목적지
- 비행기, 항로
- 비행기, 항로, 고정지점, 위도, 고도
- 비행기, 항로, 고정지점, 위도, 고도, 비행계획, 속도
- 비행, 비행계획, 항로, 고정지점, 2차원 좌표
결론 : 개발자, 도메인 전무가로 구성된 설계팀은 자신들의 행동을 통합하고, 모델 작성과 작성된 모델의 코드화를 도와줄 언어가 필요하다
