2013-10-16 2 views
4

집계 루트의 개념을 이해하고 하나의 집계 루트가 다른 ID (http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf)를 참조해야 함을 알고 있으므로 어떻게 Entity Framework에 외래 키 제약 조건을 추가 할 수 있습니까? 두 개의 집계 사이에?집계 루트 간의 외래 키

내가 단순화 된 도메인이 있다고 가정하자 :이 도메인 디자인

public class AggregateOne{ 
    [Key] 
    public Guid AggregateOneID{ get; private set;} 
    public Guid AggregateTwoFK{get; private set;} 
    /*Other Properties and methods*/ 
} 

public class AggregateTwo{ 
    [Key] 
    public Guid AggregateTwoID{get; private set;} 
    /*Other Properties and methods*/ 
} 

을, 엔티티 프레임 워크는 AggregateOne와 AggregateTwo 사이의 관계가 있다는 것을 모르는 결과적으로 생성 된 데이터베이스에서 어떤 외래 키가 없다 .

+0

내 질문은 ORM이 생각하는 것을 정말로 고려해야하는지 여부입니다. :) --- 아마도 관계가 진행될 것입니다. 어쨌든 데이터 저장소에 의해 시행되어야합니다. –

+0

CodeFirst를 사용하면서 도메인 클래스에 따라 데이터베이스가 자동으로 생성됩니다. –

+0

아, 알겠습니다. 음, * 문제가 될 수 있습니다. 분명히 나는 ​​ORM을 명확히 할 수 없으므로 모든 ins-and-outs를 가진 것이 아니라는 것을 알았지 만,이 코드를 처음 들어 보았습니다 :) --- 참조 무결성을 설정할 수 없을 것입니다. 관계를 설정하지 않아도 코드 우선부터. 데이터베이스를 만든 후에 참조 무결성을 정의해야 할 수도 있습니다. 누군가가 멋진 EF 속임수를 안다면. –

답변

6

DDD에서 EF는 존재하지 않습니다. 도메인 관계는 데이터베이스 관계와 동일하지 않습니다. 도메인 모델링과 EF를 함께 사용하지 마십시오. 함께 작동하지 않습니다. 간단히 말해 DDD가 아니라 평범한 오래된 관계형 데이터베이스가 DDD로 가장합니다. EF는 리포지토리에서 사용되며 하나의 집계 루트 (AR : Aggregate Root)를 유지하는 데 신경을 씁니다.

두 개의 AR이 함께 작동 할 수 있지만 도메인에 따라 프로세스를 모델링해야합니다. EF는 앱의 DB 역할을하기 때문에 지속성 문제와 관련이 있으며 도메인에 신경 쓰지 않아야합니다. 지속성은 스토리지에 관한 것이지 도메인 관계를 반영하는 것에 관한 것이 아닙니다 (EF 엔티티는 동일한 이름을 가질 수 있지만 비슷할 수 있지만 도메인 엔티티는 아니며 중요한 세부 사항은 서로 다른 레이어에 속하고 다른 문제를 처리한다는 것입니다). 도메인 리포지토리는 AR이 변경 될 때 쉽게 복원 할 수있는 방식으로 AR을 유지하기 만합니다. AR을 지속적으로 유지해야하는 경우 궁극적 인 일관성을 유지하고 서비스 버스 및 사가를 사용하는 방법을 배웁니다. 그것은 당신의 삶을 크게 단순화 할 것입니다 (작업 단위 패턴에 대한 일종의 구현이라고 생각하십시오).

쿼리의 경우 가장 깨끗하고 우아한 방법은 쿼리 사용 사례에 적합한 읽기 모델을 생성/업데이트하는 것이고 이는 도메인 이벤트가 도메인에서 변경된 사항을 '세계'에 알린 후에 수행됩니다.

DDD 권한을 수행하는 것은 간단하지 않으며 DDD 용어를 사용하여 실망했을 때 DDD를 적용한다고 생각하면 트랩에 빠지기 쉽습니다. 또한 당신이 쉬운 삶을 원한다면 IMO CQRS는 DDD와 필수적입니다.

도메인을 서둘러 서핑하지 않고 이해하고, 제한된 컨텍스트를 식별하고, 도메인 개념과 사용 사례를 모델링하고 (매우 중요 !!!), 필요에 따라 리포지토리 인터페이스를 정의하고, 리포지토리를 구현할 때만 리포지토리를 구현하십시오. 나머지는 아무것도 남기지 않습니다. (실제 리포지토리는 메모리 리포지토리와 같은 가짜 앱을 사용할 수 있습니다. 구현하기가 매우 빠르며 분리 된 앱은 지속성 구현에 신경을 쓰지 않아도된다는 의미입니까?). 이상하게 들리지만이 방법을 통해 유지 관리 가능한 DDD 앱을 알 수 있습니다.

마지막으로 리포지토리를 구현하는 요점은 응용 프로그램과 지속성 세부 정보를 실제로 분리하고 응용 프로그램이 지속성에서 갖는 기대치 (리포지토리 메서드)를 정의하는 것입니다. 일단 정의되면 테스트를 작성할 수 있습니다. D는 저장소를 구현합니다. 보너스는 레포 구현에만 집중할 수 있다는 것이고, 모든 테스트가 통과되면 모든 것이 제대로 작동한다는 것을 알게됩니다.

+0

그런 다음 두 개의 모델 (하나는 내 도메인 용이고 다른 하나는 Entity Framework 용)을 유지해야한다고 제안하는 중입니까? Julie Lerman (http://msdn.microsoft.com/en-us/magazine/ee532098.aspx?sdmr=JulieLerman&sdmi=authors)에서 기사를 읽었 기 때문에 약간 혼란스럽고 한 모델 만 필요하다고 생각했습니다. . –

+1

개인적으로 EF로 DDD를 시도했을 때 CRUD 전용 작업에 ORM을 사용하고 내 리포지토리가 도메인 엔티티를 수락하고 반환하는지 확인했습니다. 이렇게하면 ORM의 이점이 많이 줄어들고 코드 우선을 사용하는 경우 아마도 2 세트의 엔티티를 유지 관리하는 데 많은 추가 작업이 필요할 것입니다. 슬프게도 저는 도메인에서 EF 엔티티를 사용하고 있으며 작동하지 않는 프로젝트에서 작업하고 있습니다. RDBMS의 세부 사항이 도메인으로 유출되기 시작하면, ORM이 필요로하지 않을 것이기 때문에 ORM으로 구부리기 만합니다. –

+0

YEs 모델은 각각 다른 컨텍스트를 모델링하기 때문에 2 가지 모델이 있습니다. 물론 EF 팀의 기사를 읽는 것은 EF 만 필요하다고 말하지만 잘못된 것입니다. 그들은 제품을 밀어 붙이려고하고 있으며 앱이 EF에 밀접하게 결합되는 것을 좋아합니다. 그들은 앱의 디자인과 유지 관리에 신경 쓰지 않습니다. EF는 지속성의 세부 사항입니다. – MikeSW

0

왜 완전히 다른 두 개의 개체가 있어야합니까? 도메인 인터페이스를 통해 엔티티를 도메인 객체로 노출하는 것이 아닌가? 이 경우 엔티티가 구현 세부 사항이 인터페이스 뒤에 깔끔하게 숨겨진 도메인 객체로 작동하는 데 아무런 문제가 없습니다.

EF를 사용하여 집계 루트를 나타내는 또 다른 방법은 외부 키 열이 종속 엔터티의 기본 키를 구성하는지 확인하는 것입니다.귀하의 경우에는 AggregateOneId와 AggregateTwoFk가 함께 AggregateOne의 복합 기본 키를 형성하게됩니다. 이것은 EF가 AggregateOne의 컬렉션에서 제거되는 한 AggregateOne에서 인스턴스를 제거하기위한 저장소가 필요하지 않도록합니다. 데이터베이스에서 삭제 표시가 적절하게 표시됩니다 (이 키가 없으면 제거해야 함). AggregateOne은 개발자가 AggregateOne을 삭제해야한다는 의도를 이해하지 못하기 때문에 예외가 발생합니다.