DDD 영역 모델 개발

집계(Aggregation):
이것은 느슨한 대상 간의 관계다.예를 들어 컴퓨터와 그의 외곽 설비가 바로 예이다.
관계를 가지거나 전체와 부분의 관계를 나타내는 데 쓰인다.
결합(Composition):
이것은 매우 강한 대상 간의 관계이다. 예를 들어 나무와 나뭇잎 사이의 관계다.
하나의 합성에서 부분과 전체의 생명 주기는 모두 같다.합성된 새로운 대상은 그 구성 부분에 대한 지배권을 완전히 가지고 있다.그들의 창립과 파멸을 포함한다.
이 두 개는 아주 비슷한데,
집계:
• 집합은 일부분에 의존하지 않고 존재할 수도 있고 없을 수도 있다
• 부분 집합에 독립적으로 존재
• 일부를 잃어버리면 집합은 불완전한 느낌을 준다
• 일부 소유권은 프린터와 같은 몇 개의 집합으로 공유할 수 있다
[인터페이스를 통해 설정]
구성:
• 부분 어느 순간 어느 한 구성에만 속할 수 있다
• 고유한 책임 소재를 구성하여 모든 작업을 처리합니다. 즉, 창설 및 폐기를 책임져야 합니다.
• 일부 직책을 다른 대상이 맡는다면 구성도 이 직책을 늦출 수 있다.
• 소각을 구성하면 모든 부분을 소각하거나 그들의 권리를 다른 대상에게 이전해야 한다.
[코드 조합을 통해]
모델 구동 디자인(Model-driven Design)은 분열 분석 모델과 디자인 방법을 버리고 단일한 모델을 사용하여 이 두 가지 측면의 요구를 만족시킨다.이것이 바로 영역 모델!
영역 모델은 분석과 디자인을 함께 놓고 단일한 영역 모델은 분석 원형과 소프트웨어 디자인을 동시에 만족시킨다. 만약에 하나의 모델이 실현될 때 실용적이지 않으면 새로운 모델을 다시 찾는다.[단일한 모델로 분석과 디자인을 만족시키고 만족하지 못하면 모델을 다시 찾는다] 모델을 어떻게 찾습니까?모형은 또 뭐야?
Eric의 이론에 따르면 업무 층은 두 가지 차원으로 나눌 것이다. 그것이 바로 응용 층과 영역 층이다.
응용층: 소프트웨어가 완성할 수 있는 일을 정의하고 풍부한 의미를 가진 분야 대상을 지휘하여 문제를 해결하고 세련되게 유지한다.업무 규칙이나 지식을 포함하지 않고 업무 상황이 없는 상태;Action[이 코드가 변경될 확률은 0]입니다.
분야층: 업무 개념, 업무 상태를 나타내는 정보와 업무 규칙을 담당하는 것이 업무 소프트웨어의 핵심이다.차원 간에는 반드시 명확하게 분리되어야 하며, 각 층은 모두 내집되어 있고, 그것의 하층에만 의존해야 한다.[영역층에서 모델을 구축할 것이다. 예를 들어 사용자 모델은 사용자의 모든 속성을 보존하고 사용자의 모든 기능을 인터페이스에 대상으로 하고 하층에 의존하여 실현한다. 즉, 추상적인 방식으로 모델을 구축한다. 즉, 분석과 디자인을 할 때 설정한 사용자 모델이다. 예를 들어 다음과 같은 유형도이다]
분석과 디자인[최고급 인터페이스를 설정하는 것이 중요하다]
사용자 최상위 인터페이스 User

UserInfo  getUserInfo()  -- :  
void Speak()       -- : 
void Walk()        -- : 

         
여기를 보면 사용자 인터페이스가 매우 간단하고 간결하다고 느끼지 않을까요?[노출 외부 호출 방법은 디자인할 때 이미 확정됨]
사용자 인터페이스의 기능 내집, 사용자 모델은 사용자 속성을 저장하고 모든 기능은 인터페이스를 대상으로 하층에 의존하여 실현한다.
인터페이스 추상 클래스 AbstratorUser

UserInfo userInfo;    -- 

// .
Abstrator UserOperator getUserOperator() – ， 

//overwriter
Speak(){
             getUserOperator ().Speak();
}

//overwriter
Walk(){
			getUserOperator ().Walk();
}
// 
Void setUserInfo(UserInfo userInfo){
  This.userInfo=userInfo
}

//overwriter
UserInfo getUserInfo(){
  Return userInfo;
}

[업무 논리에 대한 초보적인 포장, 파란색 부분은 다시 쓰는 방법이고 빨간색 부분은 하층 건물에 의존해야 한다]
이상은 디자인 단계에서 완성된 것이고 하층 건축은 개발 엔지니어에게 맡겨서 완성한다. 서로 다른 개발 엔지니어의 수준과 스타일은 다를 수 있지만 완전히 분리된 방식으로 각 모듈[유저정보, 유저조작]이 정상적으로 운행되고 결합은 0이다.[이 코드가 바뀔 확률은 0]입니다.
현재 Action층 코드는 0, 인터페이스 층과 추상 층 코드는 0으로 변경되었습니다. 그러면 사용자 논리가 변할 때 하층 건물만 수정하면 됩니다!
UserInfo는 솔리드 클래스로서 객체의 등록 정보를 조합하여 연결합니다.
Address,Account,Family.Friend 등의 정보를 추가할 필요가 있으면 다른 모듈과 결합하지 않습니다.
UserOperator는 하층 건물에 의존하는 인터페이스로 사용자 조작 대상이다.만약 사용자의 Speak 방식이 중국어에서 영어로 바뀌었다면, 하층건물을 수정하기만 하면 된다.
이것이 바로 DDD이다. 분야는 개발을 구동하고 하층건물에만 의존하며 하층건물은 가장 간단한 첨삭 수정 작업이다.즉, 업무가 가장 변동이 필요한 부분이다. 영역 구동은 하나의 프로젝트를 하나의 구역으로 나눌 수 있다. 이 구역은 이 프로젝트의 모든 정보를 포함할 수 있다. 사실DDD는 새로운 기술이 아니다. 그는 단지 하나의 확률을 제공했다. 분석과 디자인의 조합은 업무를 정리하고 상부 구조의 결함을 줄일 수 있다. 하부 건축은 무작위로 바꿀 수 있고 상부 건축은 기본적인 인터페이스와 추상적이다.업무 논리에 분석 오류가 없다면 변경할 필요가 없다.한편, DDD는 층을 두 층으로 나눈다. 응용층과 분야층도 전체적으로 고려하면 응용층은 분야층의 인터페이스를 호출한다. 사실 분야층도 층을 나눌 수 있다. 그는 시스템의 기획을 더욱 간단하게 할 뿐이다. 그렇게 많은 층을 고려하지 않아도 된다. 시스템은 모두 간단에서 복잡으로 한다. 이것은 데이터 발굴 기술에 해당한다. 한 장의 그림은 매우 간단하고 다시 파도 간단하다. 다시 파도 간단하다. 서로 다른 프로젝트, 서로 다른 모듈을 응용한다.인터페이스와 추상적인 디자인을 바탕으로 전체적인 고려를 할 수 있는 것이 바로 DDD의 사상이다.
이제 영역 모델이 무엇인지 대답해 보자.
영역 모델은 영역 내의 개념류나 현실 세계의 대상을 가시화하는 표현이다.
현실인 User
사람의 속성 getUserInfo()
사람 말, Opertator.Speak()
사람이 걷는 Operator.Walk()
모델을 찾는 방법:
업무 전문가와 디자인 전문가가 교류할 때 디자인 전문가는 업무 전문가의 묘사에서 실체와 실체 간의 관계를 추출할 수 있다. [범위화, 의존과 관련, 관련은 일반적인 관련, 집합, 조합 등으로 나뉜다]