POCO 클래스를 도메인 클래스로 사용하지만 사용자 정의 링크 게터 및 설정자가 있습니까?

Question

저는 최근에 Entity Framework와 함께 작업 할 때 원본 도메인 클래스 논리와 혼합 된 POCO 클래스를 사용하여 코드 우선으로 디자인하는 것이 좋습니다.

그래서이 새로운 아이디어를 사용하기로 결정했습니다. 예전에 DatabasePerson이라는 POCO 클래스와 Person이라는 도메인 클래스가있었습니다. 이제 Entity Framework를 병합하여 Entity Framework에서 내 리포지토리를보다 효율적으로 관리하고 도메인 계층의 변경 사항을 쉽게 관리 할 수있게하려고합니다.

이제 DatabasePerson POCO 클래스에서 DatabaseAccount POCO 클래스에 대한 링크가 있습니다. 마찬가지로 Person 도메인 클래스에는 Account 도메인 클래스에 대한 링크가 있습니다. 엔티티 프레임 워크에서

링크 이러한 유형의 게으른 로딩을 허용하는, 그래서 같이합니다 ( DatabasePerson 클래스로) 가상 링크 속성을 선언

public virtual DatabaseAccount Account { get; set; }

그러나, 만약에 계정을 설정하거나 가져 오는 방법을 변경하고 null으로 설정할 때 예외를 처리하는 방법을 변경하고 싶습니다. Entity Framework가 테이블에 추가하는 것과 충돌하지 않도록하려면 어떻게해야합니까?

여기에 내 도메인 클래스 '링크입니다 : 어떻게 든 커스터마이즈의이 양식을 유지하려는

public Account Account { 
    get { 
     //maybe do some other stuff here. 
     return account; 
    } 
    set { 
     if (value == null) throw new ArgumentNullException("value"); 

     account = value; 

     //maybe do some other stuff here. 
    } 
} 

뿐만 아니라 게으른 로딩이있다. 그게 가능하니?

Answer 1

지연 구동은 도메인 구동 디자인의 개념, 특히 Aggregates의 개념과 충돌합니다. 저장소에서 집계를 검색하고 업데이트하는 작업은 단일 작업이어야합니다. 집계는 유비쿼터스 언어의 사양에 따라 완료되어야합니다. lazy 로딩을 도입하면 집계가 완전하지 않기 때문에이 규칙이 적용되지 않습니다 (또는 집계를 올바르게 정의하지 않았다는 표시 일 수도 있음).

위 내용 외에 DDD의 핵심 원칙 중 하나를 위반하는 것입니다. 기술적 관심사 (Entity Framework, 데이터베이스, 지연로드 등)의 영향으로 도메인을 설계하고 있습니다. 이러한 인프라의 '누수'를 도입하면 설계 결정을 내리는 방식이 제한됩니다. 엔티티와 값 객체는 도메인의 절대 핵심을 형성합니다. 그것들은 서로 상호 작용하는 실세계의 대상입니다. 지속성에 대한 무지는 좋은 도메인 모델을 설계하는 데 중요합니다.

나는이 개념을 좀 더 잘 이해하고자 할 때 좀 더 많은 집계를 원할 것이다.

은의 당신이 Order 개체가 포함 된 집계의 루트로 결정했다고 가정 해 봅시다 Order 및 OrderLine (AN Order 1 개 또는 여러 OrderLine 실체를 가질 수있다).이 결정은 여러 가지 이유로, 일부 복지를 기반으로 할 수 있습니다

• OrderLine를 검색하거나 독립적으로 참조 할 필요가 없습니다 그 Order
• Order는 OrderLine에 '수집'
변경에 대한 책임을 져야한다
• Order과 OrderLines는 저장소에서 Order를 가져 오는 경우

은이 집계가 형성됩니다 트랜잭션 일관성이 있어야합니다 하나의 작업 단위로 모두 OrderLines은 주문과 함께 반품되어 반환됩니다. 저장 또는 갱신 할 때, 집계도 단일 작업 단위 (UOW)에 보존됩니다. 이렇게하면 모든 엔티티 (및 그 관계)가 일관성을 유지하고 '비즈니스 규칙'을 위반하지 않게됩니다.

귀하의 경우 Person 및 그 Accounts은 단일 집계에 속하지 않는 것이 좋습니다. 나는 당신이 그 사람 자신을 검색하지 않고도 (아마도 신원을 사용하여) 사람의 계정에 액세스해야한다고 가정한다. 난 당신이 집계 외부에서 특정 계정을 참조하려는 것입니다 (집계 루트는 집계 외부에서 참조 할 수 있습니다). 또한 Account은 Person과 별개로 변경할 수 있다고 가정합니다. 아마도 당신이 Person aggregate에 속하는 것을 원하지 않는 또 다른 이유는 성능상의 이유로 인한 것입니다 (예, 때로는 우리는 실용적이어야하며 순수 주의자가되어야합니다!). 위의 모든 내용은 전적으로 귀하의 요구 사항에 달려 있습니다.

저는 개인적으로 데이터 엔티티 (일반적으로 Entity Framework 또는 다른 지속성 도구를 사용하여 데이터베이스에서 직접 매핑)와 도메인 엔티티/값 개체를 분리한다고 생각합니다. 이를 통해 데이터베이스 관련 구조, 프레임 워크 및 제약 조건을 완전히 격리하여 도메인을 설계 할 수 있습니다.