Eric Evans의 Domain Driven Design 책에서“도메인”이라는 단어는 특정한 의미를 갖습니다. 소프트웨어가 중요합니다.

에반스는 더 나아 간다. 그의 견해로는 동일한 소프트웨어로도 하위 도메인이 있습니다. 그리고 이것은 “전략적 디자인”을 다루는이 책의 일부입니다.

핵심 도메인, 지원 도메인 및 일반 도메인의 세 가지 “도메인”이 있습니다. 때때로 그는 이것을 하위 도메인이라고 부릅니다.

Evans는 또한 소프트웨어의 실제 비즈니스에 대해 깊은 관심을 가지고 있으며이 책은 개발자뿐만 아니라 소프트웨어와 비즈니스가 어떻게 협력 할 수 있는지를 알아야하는 건축가 및 관리자를 대상으로합니다. 전략적 디자인을 논의 할 때 그가 관심을 갖는 부분입니다. 그리고 이러한 하위 도메인.

따라서 핵심 영역은 소프트웨어의 경쟁 우위와“지평”을 모두 나타내는 소프트웨어의 일부입니다. 고객이 소프트웨어를 다른 소프트웨어와 비교하여 구매하는 이유는 소프트웨어의 일부입니다. 일반적으로 Evans는이 코드를 가장 적은 비율의 코드가 포함 된 도메인으로 간주합니다. 가장 중요한 20 %라고 생각할 수 있습니다. 그것은 실제로 선반에서 구입할 수없는 부분이며 전체 소프트웨어의 단일 모듈 또는 구성 요소 일 수 있습니다.

지원 도메인은 여전히 ​​중요하며 조직마다 고유 할 수 있지만 핵심 도메인만큼 중요하지는 않습니다. 그것이 없으면 소프트웨어는 가치가 없으며 핵심은 소프트웨어에 의존합니다. 소프트웨어에서 직접 작성한 여러 가지 모듈 일 수 있으며 중요하지만 지원적인 기능을 코어에 수행합니다.

일반 도메인은 사용자 정의가 가장 적고 어떤 의미에서는 소프트웨어의 가장 중요한 부분입니다. 집에서 직접 작성했을 수도 있지만 선반에서 구입하거나 잘 알려진 오픈 소스 소프트웨어를 사용하는 것이 더 효율적일 수 있습니다. 시스템의이 부분은 아마도 전체 도메인에 국한되지 않을 것입니다. 예를 들어 소포를 운송하는 운송 시스템 또는 환자를 관리하는 건강 기록 시스템이 있는지 여부에 관계없이 일반 도메인은 이러한 시스템의 일부이며 일반적입니다. 단순히 기능하기 위해서는 거기에 있어야합니다. 이것은 아마도 전체 시스템의 대부분을 구성하지만 반드시 그런 것은 아닙니다.

비즈니스 관점에서 핵심 도메인이 무엇인지 결정하고 개발 리소스에 집중하는 것이 중요합니다. Evans는 특히 InfoQ 사이트에서 이러한 개념에 대해 자세히 설명하는 많은 비디오를 보유하고 있습니다.

따라서 DDD의 경우 소프트웨어에서“도메인”에 대해 이야기하는 경우가 종종 있지만 그렇게 간단하지는 않습니다.

DDD의 개념이 더 넓은 소프트웨어 커뮤니티에 반드시 존재하는 것은 아닙니다. 다른 개발자, 저자 및 제품 사용자는 다른 아이디어와 정의를 가질 수 있습니다. DDD에 관해 저술 한 다른 저자들조차도 Evans의 저서에서 이러한 개념에 대해 글을 쓸 수도 있지만, 소프트웨어 프로젝트를 작성하고 계획 할 때이 개념이 여전히 유용하다고 생각합니다.

답변