도메인 주도 설계 구현
DDD를 시작하며
DDD는 어떻게 하는가
- 유비쿼터스 언어 : 팀내에 공유된 언어 도메인 전문가와 개발자간에 같이 공유된다.
메소드 명에도 고민을 해서 이름을 정함 해당 부분을 유비쿼터스 언어로 사용하여 코딩
문서도 시간이지나면 수정되지 않는다 코드상의 모델이 가장 지속적이고 유일하게 보장 되는 유비쿼터스 언어의 모습이다.
유비쿼터스 언어는 소프트웨어 모델 자체에 특정 핵심 비즈니스 도메인의 개념과 용어를 포착하는 데 사용되는 팀의 패턴
유비쿼터스지만 보편적이지는 않다.
유비쿼터스는 ‘만연하다.’ 혹은 ‘어디서나 발견된다.’는 의미
유비쿼터스라는 단어의 사용은 엔터프라이즈 전체의 전사적은 혹은 세계적이고 보편적인 도메인 언어를 설명하려는 의도는 아니다
바운디드 컨텍스트당 하나의 유비쿼터스 언어가 있다.
바운디드 컨텍스트는 우리가 처음 상상했던 것보다 상대적으로 더 작다.
바운디드 컨텍스트는 격리된 비즈니스 도메인의 완전한 유비쿼터스 언어를 포착할 만큼만 크다.
유비쿼터스 언어는 바운디드 컨텍스트를 격리시키고 그 안에서 프로젝트의 개발 업무를 수행하는 팀 내부에서만 유비쿼터스 하다.
하나의 바운디드 컨텍스트를 개발하는 하나의 프로젝트에는 항상 하나이상의 격리된 바운디드 컨텍스트가 있으며 이는 컨텍스트 맵을 사용해 통합된다.
당신이 전체 엔터프라이즈에 혹은 그보다 넓은 단위에 단일 유비쿼터스 언어를 적용하려 한다면 실패할것 이다.
DDD를 사용하는데서 오는 비즈니스 가치
우리는 우리가 하는 모든 행동을 정당화 해야 한다. 흥미를 끈다는 이유로 새로운 기술이나 기법을 쫒아 갈수는 없다.
어떤 기술이나 기법을 사용할때 가장 훌륭한 정당화는 비즈니스에 가치를 제공하는 경우라고 생각한다.
DDD를 도입하며 얻게 되는 아주 실제적인 비즈니스 가치
조직이 그 도메인에 유용한 모델을 얻는다. - DDD의 초점은 비즈니스적으로 중요한곳에 우리의 노력을 투자한다.
정교하고 정확하게 비즈니스를 정의하고 이해한다. - 비즈니스 자체와 비즈니스의 입무에 관해 이전보다 더 잘 이해할수 있다.
도메인 전문가가 소프트웨어 설계에 기여한다. - DDD를 위해 모두 모였을때 도메인 전문가와 개발자간에 의견의 일치를 얻게 되고 노력과 조직자체를 강화시킨다.
사용자 경험이 개선된다. - 최종 사용자 경험은 도메인의 모델을 좀 더 잘 반영함으로써 개선된다.
순수한 모델 주변에 명확한 경계가 생긴다. - 기술팀은 프로그래밍과 알고리즘적 문제에 더 많은 관심을 드러내지 않도록 권장된다. 방향의 순수성은 가장 중요한 곳에 노력을 집중할 수 있도록 한다.
엔터프라이즈 아키텍처의 구성이 좋아진다. - 바운디드 컨텍스트를 잘 이해하고 신중하게 분할한 경우, 엔터프라이즈 내의 모든팀은 어디서 왜 통합이 필요한지 분명하게 이해하게 된다.
애자일하고 반복적이고 지속적인 모델링이 사용된다. - DDD는 도메인 전문가의 심적 모델을 신중히 정제해서 비즈니스에 유용한 모델로 만드는 방법의 문제다.
전략적인 동시에 전술적인 새로운 도구가 적용된다. - 주어진 바운디드 컨텍스트를 각각 담당하기도 하는 서로 다른 팀은 컨텍스트맵을 사용해 바운디드 컨텍스트를 전략적으로 분리하고 그들 사이의 통합을 합의 한다.