DDD(도메인 중심 설계)란 무엇입니까? 이것은 내가 본 DDD에 관한 기사 중 가장 이해하기 쉬운 기사입니다.
도메인 기반 디자인의 도메인 모델
탐색을 추가하세요. 집계를 디자인하는 방법에 대한 자세한 내용은 이 문서를 참조하세요.
2004년 Eric Evans는 Evans DDD라고 하는 도메인 중심 설계 - 소프트웨어 핵심의 복잡성 처리(도메인 중심 설계)를 출판했습니다. 도메인 중심 디자인은 두 단계로 나누어집니다.
도메인 전문가, 디자이너, 개발자가 이해할 수 있는 공통 언어를 상호 소통의 도구로 사용하고, 소통 과정에서 도메인 개념을 발견한 후, 이러한 개념은 도메인 모델로 설계됩니다.
도메인 모델은 소프트웨어 설계를 주도하고 코드는 도메인 모델을 구현하는 데 사용됩니다.
도메인의 핵심은 다음과 같습니다. 중심 설계는 올바른 도메인 모델을 확립하는 것입니다.
도메인 모델 구축이 중요한 이유
도메인 중심 설계는 소프트웨어를 통해 비즈니스 시스템을 구현할 때 도메인 모델 구축이 매우 중요하고 필요하다는 것을 말해줍니다. 도메인 모델은 다음과 같은 특징을 가지고 있습니다:
00001. 도메인 모델은 특정 경계를 가진 도메인의 추상화로, 도메인에서 사용자의 비즈니스 요구 사항을 반영합니다.
00002.?도메인 모델은 비즈니스만을 반영할 뿐 기술적 구현과는 아무런 관련이 없습니다. 도메인 모델은 해당 분야의 일부 엔터티 개념만 반영할 수는 없습니다. , 상품, 서적, 신청 기록, 주소 등, 자금 이체 등 도메인의 일부 프로세스 개념을 반영할 수도 있습니다.
00003. 우리 소프트웨어의 논리는 모두 하나의 모델에 있으며, 이는 소프트웨어의 유지 관리성, 비즈니스 이해성 및 재사용성을 향상시키는 데 매우 유용합니다.
00004.? 소프트웨어 구축에 대한 지식;
00005.? 도메인 모델은 소프트웨어 분석, 설계, 개발의 전 과정을 거치며 도메인 모델을 통해 서로 소통하고 지식과 정보를 공유합니다. ; 모든 사람이 동일한 모델에 직면하기 때문에 요구 사항이 왜곡되는 것을 방지할 수 있으며 소프트웨어 디자이너와 개발자가 만든 소프트웨어는 실제로 요구 사항을 충족할 수 있습니다.
00006.? 올바른 도메인 모델을 위해서는 모든 사람이 도메인에 대해 더 깊이 이해하고 도메인 모델을 지속적으로 개선하고 개선할 수 있도록 도메인 전문가, 디자이너, 개발자의 적극적인 소통과 공동 노력이 필요합니다.
00007.? 보시다시피 도메인 모델을 표현하기 위해 몇 가지 방법을 사용해야 합니다. 다이어그램은 도메인 모델을 표현하는 데 가장 일반적으로 사용되는 방법이지만 코드나 텍스트 설명도 표현할 수 있는 유일한 방법은 아닙니다. 익스프레스 도메인 모델;
00008.? 도메인 모델은 전체 소프트웨어의 핵심이며 소프트웨어의 가장 가치 있고 경쟁력 있는 부분입니다. 잘 설계되고 비즈니스 요구를 충족하는 도메인 모델은 수요에 대응할 수 있습니다. 더 빠르게 변화합니다;
도메인 공통 언어(UBIQUITOUS LANGUAGE)
도메인 모델을 개발하기 위해서는 소프트웨어 전문가와 도메인 전문가가 협력하는 것이 절대적으로 필요하다는 것을 알고 있지만 그러한 접근 방식은 기본적인 의사소통 장벽으로 인해 어려움을 겪는 경우가 많습니다. 개발자의 마음은 클래스, 메소드, 알고리즘, 패턴, 아키텍처 등으로 가득 차 있으며 항상 실제 개념을 프로그램 결과물에 매핑하려고 노력합니다. 그들은 어떤 객체 클래스가 구축되어야 하는지, 그리고 객체 클래스 간의 관계가 어떻게 모델링되는지 알고 싶어합니다. 그들은 캡슐화, 상속, 다형성과 같은 객체 지향 프로그래밍의 개념에 대해 생각하는 데 익숙할 것이며 언제 어디서나 이런 말을 할 것입니다. 그러나 도메인 전문가는 소프트웨어 라이브러리, 프레임워크, 지속성 또는 데이터베이스에 대한 개념이 없는 경우가 많습니다.
그들은 자신의 특정 도메인 전문 지식만 알고 있습니다. 예를 들어, 항공 교통 모니터링의 예에서 도메인 전문가는 항공기, 경로, 고도, 경도 및 위도를 알고 항공기가 정상 경로를 벗어났는지 알고 항공기의 발사를 알고 있습니다. 그들은 이러한 것들을 그들 자신의 용어로 논의하는데, 때로는 평신도들이 직접 이해하기 어렵습니다. 한 사람이 다른 사람이 이해할 수 없는 말을 하거나 심지어 다른 말로 오해하는 경우, 프로젝트가 성공할 가능성은 얼마나 됩니까?
소통 과정에서 이러한 개념을 다른 사람들이 이해할 수 있도록 번역이 필요합니다. 개발자는 일반인의 관점에서 일부 디자인 패턴을 분석하려고 시도할 수 있지만 이것이 항상 작동하는 것은 아닙니다. 도메인 전문가는 이러한 아이디어를 표현하기 위해 새로운 용어를 만들 수도 있습니다. 이러한 유형의 번역은 이 고통스러운 의사소통 과정에서 지식 구축 과정에 기여하지 않습니다.
도메인 모델링 시 문제를 생각하는 관점
'사용자 요구'는 '사용자'와 동일시될 수 없고, '사용자 마음 속의 모델'을 포착하는 것도 '사용자'와 동일시될 수 없습니다. 사용자 중심 디자인 "도메인 모델". 노자(老子)라는 책에는 '무엇이 있으면 유익을 얻고 없으면 쓰게 된다'는 말이 있다. 여기서 유익한 것은 도메인 모델을 구축하는 것이고, 쓸모없는 것은 사용자 요구를 수용하는 것입니다. 몇 가지 예를 들자면, 컵은 한 컵의 물로 채워져야 합니다. 컵을 만들 때 우리는 빈 컵을 만들어야 합니다. 즉, 물이 채워지기 전에 물을 쏟아야 합니다. 집은 사람이 거주해야 한다는 것. 집을 지을 때, 지어진 집은 비어 있고, 비어 있는 공간만이 사람을 수용할 수 있다. 따라서 도메인 모델을 구축할 때 사용자의 요구를 수용할 수 있도록 사용자도 모델 외부에 배치해야 합니다.
그래서 제가 이해한 바는:
00001입니다. 도메인 모델을 설계할 때 우리는 사용자를 중심으로 문제를 생각할 수 없고 항상 사용자가 무엇을 해야 할지 생각할 수 없습니다. 오히려 객관적인 관점에서 사용자의 요구를 바탕으로 현장에서 관련된 것들을 발굴하고, 이러한 것들의 본질적인 관계와 변화하는 패턴을 문제를 생각하는 출발점으로 생각해야 합니다.
00002. 도메인 모델은 사람을 배제한 객관적인 세계 모델이지만, 도메인 모델에는 사람이 수행하는 참여자 역할이 포함되지만 일반적으로 참여자 역할이 도메인 모델에서 주요 역할을 차지하도록 두지 않습니다. , 인간이 수행하는 참여자 역할이 도메인 모델에서 주요 위치를 차지하면 소프트웨어 시스템은 인간-컴퓨터 상호 작용 시스템이고 모든 활동이 인간을 중심으로 기록되기 때문에 각 시스템의 도메인 모델을 구별할 수 없게 됩니다. 또는 추적: 예를 들어 포럼이 사람 중심인 경우 도메인 모델은 다음과 같습니다. DDD의 예에서는 사람이 게시하고, 사람이 게시물을 결합합니다. 배송업체, 배송업체 상품, 수취인이 상품을 받고 지불인이 지불하는 등의 방식으로 도메인 모델에 대해 이야기할 때 도메인은 사람에게만 의미가 있고 사람이 속하기 때문에 기본적으로 인적 요소가 제외됩니다. 도메인 범위 밖에서 사람도 도메인에 포함된다면 도메인 모델이 객관성을 유지하기 어려울 것입니다. 도메인 모델은 누가 사용하는지, 어떻게 사용하는지와는 아무런 관련이 없는 객관적인 모델입니다. 요약하자면, 도메인 모델링은 현실을 모방하기 위해 가상 공간을 구축하는 것이 아니라 실제 사람들이 사용할 수 있도록 가상 모델을 구축하는 것입니다.
도메인 중심 디자인의 고전적인 계층 아키텍처
사용자 인터페이스/표현 계층
사용자에게 정보를 제공하고 사용자 명령을 해석하는 역할을 담당합니다. 자세한 내용은 다음과 같습니다.
00001. 사용자가 표시해야 하는 데이터를 가져오도록 애플리케이션 계층에 요청합니다.
00002. 특정 사용자 명령,
애플리케이션 계층
소프트웨어가 완료해야 하는 모든 작업을 정의하는 매우 얇은 계층입니다. 외부적으로는 프레젠테이션 계층에 대한 다양한 애플리케이션 기능(쿼리 또는 명령 포함)을 제공하고, 내부적으로는 도메인 계층(도메인 개체 또는 도메인 서비스)을 호출하여 다양한 비즈니스 로직을 완성합니다.
도메인 계층
비즈니스 개념, 비즈니스 상태 정보 및 비즈니스 규칙을 표현하는 역할을 하는 도메인 모델은 이 계층에 있으며 비즈니스 소프트웨어의 핵심입니다.
인프라 계층
이 계층은 다른 계층에 대한 일반적인 기술 기능을 제공합니다. 즉, 인프라 계층은 아키텍처 및 프레임워크를 위한 지속성 메커니즘을 구현합니다. 다른 레이어의 기술적 요구 사항을 지원하기 위해;
도메인 중심 디자인 프로세스에 사용되는 패턴
모든 패턴 개요
관련 디자인
p>
Association 자체는 패턴은 아니지만 도메인 모델링 과정에서 매우 중요하므로 다양한 패턴을 탐색하기 전에 객체 간의 연관을 디자인하는 방법에 대한 논의가 필요합니다. 객체 연관의 디자인은 다음 원칙 중 일부를 따를 수 있다고 생각합니다:
00001. 객체 간의 복잡한 연관은 쉽게 객체 네트워크를 형성할 수 있으며 이는 우리에게 도움이 됩니다. 단일 개체를 이해하고 유지하는 것은 매우 불리하며, 개체 간의 경계를 구별하는 것도 어렵습니다. 또한 동시에 연관을 줄이는 것은 개체 간의 순회를 단순화하는 데 도움이 됩니다.
00002 .? 대다 연결은 비즈니스에서 중요할 수 있습니다. 당연히 우리는 일대다 관계를 나타내기 위해 집합을 사용합니다. 하지만 특히 컬렉션에 요소가 많은 경우 성능 문제를 고려해야 하는 경우가 많습니다. 이 경우 별도의 쿼리를 통해 관련 컬렉션 정보를 얻어야 하는 경우가 많습니다.
00003.? 연결을 단방향 연결로 유지하세요.
00004.? 연결을 설정할 때 연결에 대한 제한 사항이 있는지 자세히 살펴봐야 합니다. 존재하는 경우 이 제한 사항을 추가하는 것이 가장 좋습니다. 종종 이러한 제한 조건은 연관을 단순화할 수 있습니다. 즉, 다대다를 1대다로 단순화하거나 1대다를 1대1로 단순화할 수 있습니다.
엔티티
엔터티는 도메인에서 고유하게 식별되어야 하는 도메인 개념입니다. 때로는 그것이 어떤 실체인지 구별할 필요가 있기 때문입니다. 두 개의 엔터티가 있는 경우 엔터티의 다른 모든 속성이 동일하더라도 엔터티에는 수명 주기가 있으므로 엔터티는 데이터베이스에 유지될 수 있습니다. 그런 다음 어느 시점에서 다시 꺼내집니다. 따라서 엔터티에 대한 고유 식별자를 정의하지 않으면 그것이 이 엔터티인지 어떤 엔터티인지 구분할 수 없습니다.
또한 엔터티에 대해 너무 많은 속성이나 동작을 정의해서는 안 되며, 대신 연결을 찾고, 다른 엔터티나 값 개체를 검색하고, 속성이나 동작을 다른 연결된 엔터티나 값 개체로 전송해야 합니다. . 예를 들어, Customer 엔터티에는 주소 정보가 비즈니스 의미를 지닌 완전한 개념이므로 주소 개체를 정의한 다음 고객의 주소 관련 정보를 주소 개체로 전송할 수 있습니다. Address 객체가 없고 주소 정보가 Customer 객체에 직접 배치되고 다른 주소와 유사한 정보도 Customer 객체에 직접 배치되면 Customer 객체가 혼란스러워지고 구조가 명확하지 않게 되어 궁극적으로 유지 관리 및 이해가 어렵습니다.
값 개체
현장에서 모든 것이 고유 식별자를 가질 필요는 없습니다. 즉, 그것이 어떤 개체인지는 신경 쓰지 않는다는 의미입니다. 그 물건이 무엇인지 관심을 가져라. 위의 주소 객체 Address를 예로 들면, 두 고객의 주소 정보가 동일하다면 두 고객의 주소도 같다고 생각하게 됩니다. 즉, 주소 정보가 동일하다면 동일한 주소로 간주합니다. 프로그래밍 방식으로 표현하면 두 객체의 모든 속성 값이 동일하면 동일한 객체라고 생각하고 그러한 객체를 값 객체로 설계할 수 있습니다. 따라서 값 개체에는 고유 식별자가 없으며 이것이 개체와 엔터티의 가장 큰 차이점입니다.
또한, 값 개체가 동일한 개체인지 판단할 때 모든 속성이 동일한지 여부를 기준으로 합니다. 우리는 그들이 동일한 엔터티인지 구별합니다. 엔터티의 속성이 동일한지 여부에 관계없이 엔터티의 고유 식별자가 동일한지 여부만 살펴봅니다. 값 개체의 또 다른 분명한 특징은 변경 불가능하다는 것입니다. 즉, 모든 속성은 읽기 전용입니다. 속성은 읽기 전용이므로 값 개체를 공유할 때 일반적으로 두 가지 방법이 있습니다. 적용할 구체적인 방법은 실제 상황에 따라 다릅니다. 객체는 가능한 한 단순하고 다른 많은 객체를 참조하지 않도록 합니다. 왜냐하면 int a = 3과 같은 값일 뿐이므로 "3"은 전통적인 의미에서 값이라고 부르는 것입니다. 값 객체는 실제로 다음과 같이 이해될 수 있습니다. 여기서는 "3"과 같습니다. 값이기도 하지만 객체로 표현됩니다. 따라서 C# 언어에서 두 값 개체가 동일한지 비교할 때 개체의 값을 비교하기 위해 GetHashCode 및 Equals 메서드를 재정의합니다. 값 개체는 읽기 전용이지만 완전히 대체될 수 있습니다. . a의 값을 "4"(a = 4;)로 변경한 것처럼 "3"의 값을 "4"로 직접 대체합니다. 값 개체의 경우에도 마찬가지입니다. 고객의 주소 개체 참조를 수정하려는 경우 값 개체가 읽기 전용이고 분할할 수 없는 전체이기 때문에 Customer.Address.Street를 통해 수정할 수 없습니다. 다음과 같이 할 수 있습니다: Customer.Address = new Address(...);
애플리케이션 계층 서비스
00001.? 입력 가져오기(예: XML 요청);
00002.?도메인 계층 서비스에 메시지를 보내고 전송의 비즈니스 로직을 구현하도록 요청합니다.
00003.?도메인 계층 서비스가 성공적으로 처리되면 기본 계층 서비스 이메일 알림을 보내도록 호출됩니다;
도메인 레이어 서비스
00001.? 원본 계정과 대상 계정을 획득하고 원본 계정과 대상 계정에 각각 금액을 공제하도록 알립니다.
00002.?반환 결과를 애플리케이션 계층에 제공;
기본 계층 서비스
애플리케이션 계층의 요청에 따라 이메일 알림 보내기 ;
그래서 위의 예에서 각 서비스의 책임을 명확하게 볼 수 있습니다.
Aggregation 및 Aggregate Root(Aggregate, Aggregate Root)
개체 간의 명확한 소유권 관계와 경계를 정의하여 도메인 모델을 구현하는 집계는 응집력이 있으며 복잡하고 유지 관리하기 어려운 개체 관계 네트워크의 형성을 방지합니다. 집계는 응집력 있는 관계를 가진 관련 개체 집합을 정의합니다. 우리는 집계를 데이터를 수정하는 단위로 간주합니다.
집계에는 다음과 같은 특징이 있습니다.
00001.? 각 집계에는 루트와 경계가 있습니다. 경계는 집계 내부에 있는 엔터티 또는 값 개체를 정의합니다. 엔터티;
00002.? 집계 내의 개체는 서로를 참조할 수 있지만 집계 외부에서 집계 내부의 개체에 액세스하려면 집계 루트를 통해 탐색을 시작해야 합니다. 집계 루트를 우회하지 마십시오. 집계 루트가 외부에서 해당 개체에 대한 참조를 유지할 수 있는 유일한 요소임을 의미합니다.
00003.? 루트를 제외한 집계의 엔터티는 로컬 식별자입니다. 즉, 집계 내에서 고유하게 유지되는 한, 이들은 항상 이 집계에 종속되기 때문입니다.
00004.? 다른 외부 개체를 처리하고 자체 내부 비즈니스 규칙을 유지합니다.
00005. 위의 집계 개념을 기반으로 데이터베이스에서 쿼리할 때의 단위도 하나의 단위로 집계된다는 것을 추론할 수 있습니다. 집계 내부의 루트가 아닌 개체를 직접 쿼리할 수 없습니다.
00006.?집계 내부의 개체는 다른 집계 루트에 대한 참조를 유지할 수 있습니다.
00007.?집계를 삭제할 때 루트의 경우 집계에서 관련된 모든 개체도 모두 삭제해야 합니다. 집계는 모두 동일한 개념에 속하기 때문입니다. 집계는 완전한 개념입니다.
집계 루트를 식별하는 방법은 무엇입니까?
aggregate에 엔터티가 하나만 있으면 이 엔터티가 Aggregate 루트이고, 여러 엔터티가 있으면 Aggregate에서 어떤 개체가 독립적인 의미를 가지며 외부와 직접 상호 작용할 수 있는지 생각해 볼 수 있습니다.
팩토리
DDD에 있는 팩토리도 캡슐화라는 개념을 구현한 모델이다. DDD에서 팩토리 패턴을 도입한 이유는 때로는 도메인 객체를 생성하는 것이 단순한 새로운 작업이 아니라 더 복잡한 문제이기 때문입니다. 객체가 내부 구현을 캡슐화하는 것처럼(객체의 내부 구현을 알지 못해도 객체의 동작을 사용할 수 있음), 팩토리는 특히 집계할 때 복잡한 객체를 생성하는 데 필요한 지식을 캡슐화하는 데 사용됩니다. 공장은 객체를 생성하는 것입니다. 세부 사항은 숨겨져 있습니다. 클라이언트는 몇 가지 간단한 매개변수를 팩토리에 전달하고, 그러면 팩토리는 내부적으로 복잡한 도메인 객체를 생성하여 클라이언트에 반환할 수 있습니다.
도메인 모델의 다른 요소는 이 작업에 적합하지 않으므로 이 새로운 모델인 팩토리를 도입해야 합니다. 공장이 복잡한 도메인 객체를 생성할 때 일반적으로 충족해야 할 비즈니스 규칙이 무엇인지 알고 있습니다(객체를 먼저 인스턴스화하는 방법을 알고 객체에 대해 어떤 초기화 작업이 수행되는지 알고 있습니다. 이 지식은 객체 생성에 대한 세부 정보입니다). 전달된 경우 매개변수가 객체 생성에 대한 비즈니스 규칙을 준수하면 해당 객체가 원활하게 생성될 수 있지만, 유효하지 않은 매개변수 또는 기타 이유로 인해 예상 객체를 생성할 수 없는 경우에는 예외를 발생시켜 보장해야 합니다. 잘못된 객체가 생성되지 않는다는 것입니다. 물론, 항상 팩토리를 통해 객체를 생성할 필요는 없습니다. 사실 대부분의 경우 도메인 객체 생성은 그다지 복잡하지 않기 때문에 생성자를 사용하여 객체를 생성하기만 하면 됩니다. 객체 생성을 숨기는 것의 이점은 분명합니다. 이는 도메인 계층의 비즈니스 로직이 애플리케이션 계층으로 유출되는 것을 방지하고, 애플리케이션 계층의 부담도 줄여주기 때문에 원하는 객체를 생성하기만 하면 됩니다.
리포지토리
00001. 리포지토리는 이러한 이유로 설계되었습니다. 도메인 모델의 개체는 생성된 이후 메모리에서 활성 상태로 유지되지 않으며 데이터베이스에 유지됩니다. 비활성 상태이고 필요할 때 객체를 재구축하는 것은 데이터베이스에 저장된 객체의 상태를 기반으로 객체를 다시 생성하는 프로세스입니다. 따라서 재구성된 객체는 A 프로세스임을 알 수 있습니다. 데이터베이스를 다루는 것입니다. 더 넓은 관점에서 볼 때 우리는 특정 조건에 따라 컬렉션과 같은 장소에서 하나 또는 일부 개체를 가져오거나 컬렉션에 개체를 추가하거나 컬렉션에서 개체를 제거하는 경우가 많습니다.
즉, 객체 관리에 도움이 되는 컬렉션과 유사한 인터페이스를 제공할 수 있는 메커니즘을 제공해야 합니다. 웨어하우징은 이 아이디어를 기반으로 설계되었습니다.
도메인 모델 설계를 위한 일반적인 단계
00001.? 요구 사항을 기반으로 예비 도메인 모델을 설정하고 몇 가지 명확한 도메인 개념과 그 상관 관계를 식별합니다. 상관 관계는 일시적으로 방향이 없을 수 있지만 이러한 관계(1:1, 1:N, M:N)가 있어야 하며 각 필드 개념의 의미와 포함된 주요 정보를 단어로 모호함 없이 정확하게 설명할 수 있습니다. /p>
00002. 주요 소프트웨어 애플리케이션 기능을 분석하고 주요 애플리케이션 계층 클래스를 식별하면 애플리케이션 계층의 책임과 도메인 계층의 책임을 조기에 발견하는 데 도움이 됩니다.
00002.?p>
00003.?도메인 모델을 추가로 분석하여 엔터티, 값 객체, 도메인 서비스를 식별합니다.
00004.?연관성을 분석합니다. 비즈니스에 대한 심층 분석과 다양한 소프트웨어 설계 원칙 및 성능 균형을 통해 연결 방향을 명확하게 하거나 일부 불필요한 연결을 제거합니다.
00005.? ; 분석 과정에서 명확하게 판단하기 어려운 모호한 선택 문제가 자주 발생하기 때문에 올바른 집계 루트를 찾으려면 어느 정도 분석 경험이 축적되어야 합니다.
00006.? 웨어하우스가 있는 집계 루트는 일반적으로 웨어하우스를 집계에 할당하는 것입니다. 이때는 웨어하우스의 인터페이스만 디자인하면 됩니다.
00007. 우리가 설계한 모델은 효과적일 수 있습니다.
00008. 팩토리를 통하거나 생성자를 통해 직접 도메인 엔터티 또는 값 개체를 만드는 방법을 고려하세요.
00009. 모델. 예를 들어, 일부 객체는 관련 탐색을 통해 획득해야 합니까, 아니면 창고에서 획득해야 합니까? 집계가 올바르게 설계되었습니까? 모델의 성능 등을 고려;
작업 단위의 여러 구현 방법
00001.? 스냅샷 기반 구현, 즉 도메인 개체가 제거됩니다. 백업 개체가 먼저 저장되고 지속 작업을 수행할 때 최신 개체의 상태와 백업 개체의 상태가 동일하지 않은 경우 수정된 것으로 간주됩니다. 그러면 지속성이 수행됩니다. 이 설계의 장점은 개체가 자신의 상태가 수정되었음을 작업 단위에 알릴 필요가 없다는 것입니다. 그러나 단점도 분명합니다. 객체 자체가 매우 복잡할 때 객체를 백업하고 객체의 상태가 수정되었는지 비교하는 것은 시간이 많이 걸리는 단계이며, 객체의 전체 복사본을 실제로 구현하고 속성이 변경되었는지 확인하는 것은 여전히 어렵습니다. 수정되었습니다;
00002.? 스냅샷을 기반으로 한 것이 아니라 웨어하우징에 대한 관련 업데이트 또는 새 업데이트를 기반으로 합니다. 추가 또는 삭제 인터페이스가 호출되면 웨어하우스는 개체가 있음을 작업 단위에 알립니다. 추가, 업데이트 또는 삭제되었습니다. 이러한 방식으로 작업 단위는 데이터 지속성을 수행할 때 어떤 개체가 유지되어야 하는지 알 수 있습니다. 이 방법은 이론적으로 ORM 프레임워크의 지원을 필요로 하지 않으며 동시에 도메인 모델에 대한 성향도 없습니다. 또한 장치의 모드를 매우 잘 지원합니다. 이 방법은 고급 ORM 프레임워크를 사용하고 싶지 않은 사람들에게 적합합니다.
도메인 계층의 도메인 개체 상태에 영향을 주지 않는 쿼리 기능의 경우
다음을 수행할 수 있습니다. 필요한 데이터를 통해 결과를 직접 쿼리합니다. 그러나 일반 도메인 계층의 저장소에서 제공하는 쿼리 기능은 인터페이스 표시 요구를 충족하지 못할 수 있으며 실제로 표시해야 하는 데이터를 얻기 위해 다른 저장소를 여러 번 호출해야 할 수도 있습니다. 쿼리에 대해서는 나중에 CQRS 아키텍처를 통해 직접 구현할 수 있습니다.
즉, 쿼리의 경우 구성 매개변수를 직접 사용하는 등 도메인 계층에서 아무것도 호출하지 않고 애플리케이션 계층에서 다른 기술 아키텍처로 구현된 다른 쿼리 엔진을 통해 직접 쿼리를 완료할 수 있습니다. 데이터베이스에 있는 하나 이상의 테이블에서 표시하려는 데이터를 쿼리하는 SQL입니다. 이는 고성능을 제공할 뿐만 아니라 도메인 계층의 부담도 줄여줍니다. 인터페이스에 표시되는 데이터는 보고서처럼 객체가 아닌 개념 정보인 여러 객체의 조합인 경우가 많기 때문에 도메인 모델은 애플리케이션 계층에 대한 다양한 쿼리 서비스를 제공하는 데 적합하지 않습니다.
Oriented 객체의 본질은 경계 분할과 캡슐화입니다. 이는 요구 사항의 변경을 정량화하고 영향을 줄일 수 있을 뿐만 아니라 경계 분할은 오류의 영향 범위도 제한하므로 OO는 버그와 같은 오류에도 좋습니다. 소프트웨어의 후반 단계에서.
소프트웨어 세계에는 항상 버그가 있고 버그를 제거할 수 없는 것처럼 인간 세상에도 항상 불완전함과 어두운 면이 있는 것처럼 문제의 핵심은 하나님이 경계를 사용하신다는 것입니다. 인간 세상에 고통과 재난을 가져올 수 있는 공간과 시간. 불완전성은 특정 범위에 국한되며, 소프트웨어 세계에서는 OO 및 기타 방법을 사용하여 경계를 정의하지 않으면 일단 문제가 발생하면 얼마나 심할까요? 당신이 그것을 다시 추적한다면?
소프트웨어 세계는 사실 인간의 현실 세계와 비슷하다. 가끔 뭔가 잘못되는 경우가 있는데, 그 원인을 살펴보면 겉보기에 관련이 없어 보이는 두 가지 요인으로 인해 발생하는 경우가 많다. 우리 프로그래머들은 온라인에서 실행될 때 큰 실수가 없도록 신에게 기도하고 있을 것입니다. 하지만 미리 경계를 정했기 때문에 실수하는 일도 없을 것이고, 추적하기 어려운 악마적인 버그도 없을 것입니다.
4색 원형 분석 모드
순간 간격 원형
특정 순간 또는 특정 기간 내에 발생한 활동을 나타냅니다. 분홍색으로 표시하며 약어로 MI라고 합니다.
Part-Place-Thing Archetype(Part-Place-Thing Archetype)
활동에 참여하는 사람이나 사물을 나타내며, 장소는 활동이 일어나는 장소이다. 녹색을 사용하세요. 약어는 PPT입니다.
설명 원형
PPT의 필수 설명을 나타냅니다. PPT 분류가 아닙니다! 설명은 PPT에서 추상화된 불변의 고유 속성 모음입니다. DESC로 약칭하는 파란색을 사용합니다.
예를 들어 장산이라는 사람이 있는데, 외계인이 장산이 뭐냐고 묻는다면? 당신은 무엇을 말하겠습니까? 장산은 인간이라고 할 수 있지만 외계인은 '인간'이 무엇인지 모릅니다. 그러면 당신은 무엇을 할 것인가? 당신은 장산(張san)은 머리, 두 손, 두 발, 몸으로 구성된 객관적인 존재라고 말할 것입니다. 비록 외계인들은 아직 인간이 무엇인지 알지 못하지만, 나는 이미 이 예를 사용하여 "설명"이 무엇인지 모든 사람에게 설명할 수 있습니다. 이 예에서 장산은 PPT이고, "머리, 두 손, 두 발, 몸으로 구성된 객관적인 존재"는 장산에 대한 설명이고, 머리, 손, 발, 몸은 사람입니다. 필수적이고 불변적이며 기본적인 속성의 모음입니다. 그러나 우리 인간은 더 똑똑하고 추상적인 요약과 명명에 능숙합니다. 우리는 이 설명을 "인간"이라는 한 단어로 대체했습니다. 그러므로 장산(張山)도 사람이라는 말이 있다.
역할 원형
역할은 우리가 일반적으로 "정체성"으로 이해하는 것입니다. 역할(Role)로 축약하여 노란색을 사용합니다. 역할이라는 개념은 왜 존재하는가? 일부 활동에서는 특정 역할(ID)을 가진 PPT(참여자)만 활동에 참여할 수 있도록 허용하기 때문입니다.
예를 들어, 교사 역할이 있는 경우에만 수업(활동)을 들을 수 있고, 합법적인 시민인 경우에만 선거에 참여할 수 있지만 일부 활동에는 역할이 필요하지 않습니다. , 사람은 어떤 역할(활동) 없이도 잠을 잘 수 있습니다. 물론, 사람이 역할 없이 잠을 잘 수 있다고 말하는 것은 사실 잘못된 것입니다. 이렇게 이해할 수 있기 때문입니다. 객관적 존재가 '인간' 성격을 갖고 있는 한 잠을 잘 수 있습니다. 사실 이때 우리는 이미 DESC를 성격으로 간주했습니다. 그러므로 실제로 역할의 개념은 매우 광범위하고 우리가 일반적으로 이해하는 좁은 의미의 '정체성'으로는 이해할 수 없다. 왜냐하면 '교사', '법적 시민', '사람' 모두가 역할로 취급될 수 있기 때문이다. 따라서 모든 활동에는 특정 역할을 가진 참가자가 참여해야 한다고 해야 합니다.
4색 프로토타입을 한 문장으로 요약하면, 어떤 사람, 조직, 사물이 어떤 순간에 어떤 활동에 참여하거나, 어떤 역할을 하며 어떤 기간 내에 참여하는가이다. . 그 중 "무언가"는 DESC, "사람, 조직 또는 사물"은 PPT, "역할"은 역할, "특정 순간이나 일정 기간 내의 활동"은 MI입니다.
DDD를 배우고 위의 내용을 공부하시면 DDD에 대한 이해가 더 깊어지겠지만, 이미 DDD를 이해한 것을 바탕으로 공부한다면 DDD는 비교적 기본이라고 생각합니다. 더 효과적이고 마스터하기가 더 쉽습니다.