Domain Driven Design은 문제 도메인 내의 활동, 작업, 이벤트 및 데이터를 솔루션 도메인의 기술 아티팩트로 매핑하는 복잡한 시스템 개발을위한 방법론 및 프로세스 처방입니다.
Domain Driven Design의 강조점은 문제 영역의 추상 모델을 작성하여 특정 기술 세트에서 구현할 수 있도록 문제 영역을 이해하는 것입니다. 방법론으로서의 도메인 중심 설계는이 모델 개발 및 기술 개발로 인해 시스템을 사용하는 사람들의 요구를 충족시키는 동시에 문제 영역의 변화에도 견딜 수있는 시스템을 만드는 방법에 대한 지침을 제공합니다.
도메인 기반 설계의 프로세스 측면에는 도메인 전문가, 문제 도메인을 아는 사람들 및 설계 / 아키텍처 전문가, 솔루션 도메인을 아는 사람들 간의 협업이 포함됩니다. 아이디어는 공유 언어가있는 공유 모델을 가져서 서로 다른 두 가지 관점을 가진이 두 도메인의 사람들이 솔루션에 대해 토론 할 때 실제로 공유 개념을 가진 공유 기술 자료를 논의하고 있습니다.
특정 시스템을 필요로하는 사람들과 시스템을 설계하고 구현하는 사람들 사이의 공유 된 문제 영역 이해의 부족은 성공적인 프로젝트의 핵심 장애인 것 같습니다. 도메인 기반 디자인은이 장애를 해결하는 방법입니다.
그것은 객체 모델을 갖는 것 이상입니다. 문제의 영역 내에서 실제 요구 사항을 발견하고 해당 요구 사항을 충족시키기 위해 적절한 솔루션을 작성할 수 있도록 공유 커뮤니케이션 및 협업 개선에 중점을 둡니다.
도메인 주도 디자인 : 선과 도전 은이 의견에 대한 간략한 개요를 제공합니다.
DDD는 최상위 아키텍처를 발견하고 소프트웨어를 복제해야하는 도메인의 역학 및 역학에 대해 알려줍니다. 구체적으로, 잘 수행 된 DDD 분석은 도메인 전문가와 소프트웨어 설계자 간의 오해를 최소화하고 그에 따른 값 비싼 변경 요청을 줄입니다. 더 작은 컨텍스트에서 도메인 복잡성을 분할함으로써 DDD는 프로젝트 설계자가 부풀린 오브젝트 모델을 설계하지 않아도됩니다. 부풀린 오브젝트 모델은 구현 세부 사항을 처리하는 데 많은 시간이 손실되는 부분입니다. 회의실 화이트 보드의 크기.
또한 짧은 기사 를 제공하는 이 문서의 서비스 아키텍처 를 위한 도메인 기반 설계도 참조하십시오 . 이 문서에서는 도메인 기반 디자인에 대한 다음 축소판 그림 설명을 제공합니다.
Domain Driven Design은 사용 사례와 관련된 비즈니스 현실을 기반으로 모델링을 옹호합니다. 이제는 나이가 들고 과대 광고 수준이 감소함에 따라 DDD 접근 방식이 실제로 문제를 이해하고 솔루션을 공통적으로 이해하도록 소프트웨어를 설계하는 데 실제로 도움이된다는 사실을 잊고 있습니다. 응용 프로그램을 작성할 때 DDD는 도메인 및 하위 도메인과 같은 문제에 대해 이야기합니다. 독립적 인 단계 / 문제 영역을 경계 컨텍스트로 설명하고, 이러한 문제에 대해 이야기 할 공통 언어를 강조하며, 구현을 지원하기 위해 엔티티, 가치 개체 및 집계 루트 규칙과 같은 많은 기술 개념을 추가합니다.
Martin Fowler는 방법론으로서 Domain Driven Design이 언급 된 많은 기사를 작성했습니다. 예를 들어이 기사 BoundedContext 는 Domain Driven Development의 경계 컨텍스트 개념에 대한 개요를 제공합니다.
어린 시절에 우리는 전체 비즈니스의 통합 모델을 구축하도록 권고 받았지만 DDD는 "대형 시스템에 대한 도메인 모델의 전체 통합이 실현 가능하지 않거나 비용 효율적이지 않을 것"이라는 것을 알게되었습니다 1 . 대신 DDD는 큰 시스템을 경계 컨텍스트로 분할합니다. 각 컨텍스트는 통합 모델을 가질 수 있습니다. 본질적으로 MultipleCanonicalModels을 구성하는 방법입니다.