DDD 엔티티 프레임 워크 데이터 모델을 도메인 모델로 매핑

Question

인프라 문제와 도메인 자체 간의 결합을 피하기 위해 엔티티 데이터 모델을 실제 도메인 모델과 분리해야한다는 것을 알고 있지만 모든 도메인 속성에 공용 설정자가 없으면 궁금합니다. 특히 저장소 구현이 프로젝트의 하부 구조 부분에있는 경우 데이터 모델에서 도메인 모델로 매핑 할 수 있으므로 내부 속성 설정자를 사용할 수 없습니다. 당신이 중간 "데이터 모델"이 스키마에서

class DomainModel 
{ 
    string SomeProperty {get; private set:} 
} 

Answer 1

는, 엔티티 프레임 워크는 더 이상 도메인 개체가 인스턴스화하는 방법을 제어 할 수 없습니다. 귀하의 저장소가 있습니다. 그래서 그들은 반드시 공공 세터가 필요하지 않습니다, 당신은 또한 생성자를 사용하여 그들을 rehydrate 수 있습니다.

하나는 이러한 기술은 여기에 설명 : 간단한 대안은 추가 데이터 모델을 방지하고 개인 세터 (https://lostechies.com/jimmybogard/2014/04/29/domain-modeling-with-entity-framework-scorecard/ 참조)은 거의 영향을 고려하는 경우, EF 당신의 엔티티에 미칠 사용할 수 있다는 것을 https://vaughnvernon.co/?p=879가

주 합리적인 거래.

Answer 2

나는 엔티티 데이터 모델이

진정한 인프라 우려와 도메인 자체 사이

피하기 커플 링

진실하지 실제 도메인 모델로부터 분리되어야 함을 이해

---

CAN EF를 사용하여 도메인 모델을 직접 유지할 수 있지만 도메인 모델을 EF에 연결하면 안됩니다.

어떻게 생겼습니까?

의 당신이 그것을 당신의 모델이 Domain라는 프로젝트, 지금 보통 EF 당신은 속성과 모든 종류를 사용합니다 (EF를 사용하여)는 상기 모델

을 유지하기 위해 당신의 저장소가있는 다른라는 DataStore 있다고 가정 해 봅시다 당신이 유지하기를 원하는 모델에 대해서는 말도 안되지만, &은 이러한 모델을 저장 메커니즘으로 EF에 연결합니다. &은 순수한 Domain 프로젝트의 EF에 의존성을 추가합니다. 이것은 우리가 피하려고하는 것입니다.

EF6을 구하고 EF6 FluentApi을 보면 Domain 프로젝트에 EF 특정 특성이나 종속성을 추가하지 않고도 EF와 함께 작동하도록 도메인 모델을 구성 할 수 있습니다.

기본 키?

modelBuilder.Entity<OfficeAssignment>().HasKey(t => t.InstructorID); 

색인?

modelBuilder 
.Entity<Department>() 
.Property(t => t.Name) 
.HasColumnAnnotation("Index", new IndexAnnotation(new IndexAttribute())); 

지금이 당신이 할 수있는 그런

당신은 각각의 모든 개체에 대해이 작업을 수행 할 경우 신속하게 통증이 될 것입니다,하지만 당신은 몇 가지 규칙에 충실 경우 (또는 기본 유형을 사용이 더욱 쉬워을 만들기 위해) 리플렉션을 사용하여 도메인의 모든 엔티티에 대해 auto-magically

행운을 빌어 요.