소프트웨어 아키텍처 ( "도메인 모델", "도메인 기반 디자인"등)와 관련하여이 용어를 많이 봅니다. 나는 그것을 봤지만 많은 다른 정의를 얻습니다. 그래서 진짜 무엇입니까?

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

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

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

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

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

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

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

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

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

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

도메인은 당신이 소프트웨어를 사용하여 문제를 해결하기 위해 시도하고있는 실제 상황입니다. 각 도메인에는 해당 도메인의 일부인 전문 지식, 어휘 및 도구가 제공됩니다.

도메인의 특정 예는 "고속 회전 커터를 사용하여 복잡한 부품을 자동으로 가공"과 같은 것일 수 있습니다. 이를 달성하는 소프트웨어 및 하드웨어 시스템을 CNC 밀 이라고합니다 .

도메인의 또 다른 예는 회사의 회계 부서입니다.

Martin Fowler의 추가 읽기
경계 컨텍스트

예를 들어 전자 상거래 웹 사이트를 구축하는 경우 도메인은 "전자 상거래"가되며 고객 / 회사의 영업 관행과 관련된 프로세스를 포함하게됩니다. 따라서 도메인 모델은 제품, 송장 또는 운송 기록을 나타내는 것입니다.

도메인 지식의 영역입니다. 소프트웨어에 의해 해결 된 문제가 존재하는 활동 일 수 있습니다. ( 위키 , DDD 커뮤니티 )

Eric Evans는 책에서화물 운송을 사용하여 DDD가 무엇인지 설명합니다. 그의 예에서 도메인 은 배송 에 관한 모든 것 입니다. 화물의 이동, 관리, 선적 및 추적 방법. 고유 한 특정 규칙, 언어 및 프로세스가 제공됩니다. 도메인 모델, 객체, 서비스 등이 생성됩니다.

응용 프로그램을 만들면 실제 운송 세계와 마찬가지로 일종의 인증이 제공되므로 모든 사람이 창고에 액세스 할 수있는 것은 아닙니다. 정보가화물 운송과 관련이 없을 수 있기 때문에 사용자 권한 부여 방법과 권한 부여 방법은 도메인 외부에있을 수 있습니다 .

간단히 말해서 도메인 은 비즈니스 를 수행하는 곳 입니다. 귀하의 비즈니스가화물을 운송하는 경우 – 운송화물이 귀하의 도메인이됩니다. 귀하의 비즈니스가 직원을 인증하고 권한을 부여하는 경우 이것이 귀하의 도메인이됩니다.

에서 도메인 기반 디자인 : 소프트웨어의 심장에 복잡성을 태클 , 에릭 에반스 :

모든 소프트웨어 프로그램은 사용자의 활동이나 관심사와 관련이 있습니다. 사용자가 프로그램을 적용하는 주제 영역 은 소프트웨어 의 도메인 입니다.

항공 예약 프로그램의 영역에는 실제 사람들이 실제 항공기를 타는 것이 포함됩니다.

회계 프로그램의 영역은 돈과 재무입니다.

소스 코드 제어 시스템의 도메인은 소프트웨어 개발 자체입니다.

도메인 모델은 도메인 전문가의 머리에있는 지식을 "엄격하게 구성되고 선택적으로 추상화"합니다.

팔레르모는 양파 아키텍처를 설명하면서이 요약을 제공했습니다.

가장 중심에 우리는 도메인 모델을 볼 수 있습니다. 도메인 모델은 조직의 진실을 모델링하는 상태와 행동 조합을 나타냅니다.

파울러는 차례로

동작과 데이터를 모두 포함하는 도메인의 객체 모델.

최신 정의를보고있는 경우 도메인 모델과 데이터 모델이 다른 참조가 발생할 가능성이 높습니다 . 나는 강조의 변화만큼 의미의 변화가 있다고 생각하지 않습니다-행동을 모델링하는 것 (모델 외부의 정보에 따라 데이터가 변경되는 방식)은 물건을 쓰는 다른 방법보다 더 복잡하고 다양합니다. .

도메인이 무엇인지 이미 알고있을 것이므로 다음 단계는 하위 도메인, 도메인 모델 및보다 중요한 경계 컨텍스트를 정의하는 것입니다.

나는 도메인에 대한 나의 관점을 두는 것으로 시작한다.

도메인

도메인은 우리가 살고있는 현실입니다. 그 실체, 그들의 행동, 그들이 준수하는 법. 그것은 우리 앞에 존재했고 우리 뒤에 존재합니다. 그것의 존재는 우리의 인식에 의존하지 않습니다. 마케팅 담당자는 새로운 기능을 제공하고 시장 분석을 수행하며, 주요 계정 관리자는 고객과 의사 소통하고 소프트웨어 개발자는 비즈니스 프로세스를 자동화합니다. 그래서 도메인을 문제 공간이라고합니다.

하위 도메인

DDD는 도메인을 하위 도메인으로 분해하여 모델링 및 이해를 용이하게합니다. 비즈니스를 운영한다는 사실은 적어도 하나의 지배적 인 비즈니스 가치가 있다고 추론합니다. 당신이 돈을 버는 것. 우리가 사업을 시작한 사람 따라서 "핵심 도메인"과 같은 단어를 모르더라도 여전히 존재합니다. 하위 도메인에도 동일하게 적용됩니다. 아마도 부기, 인적 자원, 기술 지원이 필요할 것입니다.

도메인 모델

추출 된 하위 도메인을 전체적으로 모델링 할 필요는 없습니다. 우리가 관심을 갖고있는 각 하위 도메인에는 특정 규칙 세트가 있습니다. 특정 비즈니스 결과를 달성하는 데 필요한 일부 하위 도메인의 규칙 세트를 모델이라고합니다.

바운드 컨텍스트

가장 중요한 것은 경계 컨텍스트가 논리적 경계라는 것입니다.

하위 도메인과 핵심 도메인이 모두 정의되면 코드를 구현해야합니다. 경계 컨텍스트는 일부 하위 도메인의 적용 가능성에 대한 실질적인 경계를 정의합니다. 특정 하위 도메인이 의미가있는 영역이지만 다른 하위 도메인은 그렇지 않습니다. 대화, 프리젠 테이션, 아티팩트에 의해 정의 된 물리적 경계가있는 코드 프로젝트 일 수 있습니다.

무엇 향후 계획?

경계 컨텍스트 개념이 하위 도메인 개념과 어떻게 관련되는지, 하위 도메인 및 경계 컨텍스트를 정의하는 방법, 서로의 의사 소통을 나타내는 방법 및 이러한 개념을 가진 팀을 구성하는 방법에 관심이 있다면 아마도 이것에 관심이있을 것입니다 더 읽기 .