DDD에서 EF는 존재하지 않습니다. 도메인 관계는 데이터베이스 관계와 동일하지 않습니다. 도메인 모델링과 EF를 함께 사용하지 마십시오. 함께 작동하지 않습니다. 간단히 말해 DDD가 아니라 평범한 오래된 관계형 데이터베이스가 DDD로 가장합니다. EF는 리포지토리에서 사용되며 하나의 집계 루트 (AR : Aggregate Root)를 유지하는 데 신경을 씁니다.
두 개의 AR이 함께 작동 할 수 있지만 도메인에 따라 프로세스를 모델링해야합니다. EF는 앱의 DB 역할을하기 때문에 지속성 문제와 관련이 있으며 도메인에 신경 쓰지 않아야합니다. 지속성은 스토리지에 관한 것이지 도메인 관계를 반영하는 것에 관한 것이 아닙니다 (EF 엔티티는 동일한 이름을 가질 수 있지만 비슷할 수 있지만 도메인 엔티티는 아니며 중요한 세부 사항은 서로 다른 레이어에 속하고 다른 문제를 처리한다는 것입니다). 도메인 리포지토리는 AR이 변경 될 때 쉽게 복원 할 수있는 방식으로 AR을 유지하기 만합니다. AR을 지속적으로 유지해야하는 경우 궁극적 인 일관성을 유지하고 서비스 버스 및 사가를 사용하는 방법을 배웁니다. 그것은 당신의 삶을 크게 단순화 할 것입니다 (작업 단위 패턴에 대한 일종의 구현이라고 생각하십시오).
쿼리의 경우 가장 깨끗하고 우아한 방법은 쿼리 사용 사례에 적합한 읽기 모델을 생성/업데이트하는 것이고 이는 도메인 이벤트가 도메인에서 변경된 사항을 '세계'에 알린 후에 수행됩니다.
DDD 권한을 수행하는 것은 간단하지 않으며 DDD 용어를 사용하여 실망했을 때 DDD를 적용한다고 생각하면 트랩에 빠지기 쉽습니다. 또한 당신이 쉬운 삶을 원한다면 IMO CQRS는 DDD와 필수적입니다.
도메인을 서둘러 서핑하지 않고 이해하고, 제한된 컨텍스트를 식별하고, 도메인 개념과 사용 사례를 모델링하고 (매우 중요 !!!), 필요에 따라 리포지토리 인터페이스를 정의하고, 리포지토리를 구현할 때만 리포지토리를 구현하십시오. 나머지는 아무것도 남기지 않습니다. (실제 리포지토리는 메모리 리포지토리와 같은 가짜 앱을 사용할 수 있습니다. 구현하기가 매우 빠르며 분리 된 앱은 지속성 구현에 신경을 쓰지 않아도된다는 의미입니까?). 이상하게 들리지만이 방법을 통해 유지 관리 가능한 DDD 앱을 알 수 있습니다.
마지막으로 리포지토리를 구현하는 요점은 응용 프로그램과 지속성 세부 정보를 실제로 분리하고 응용 프로그램이 지속성에서 갖는 기대치 (리포지토리 메서드)를 정의하는 것입니다. 일단 정의되면 테스트를 작성할 수 있습니다. D는 저장소를 구현합니다. 보너스는 레포 구현에만 집중할 수 있다는 것이고, 모든 테스트가 통과되면 모든 것이 제대로 작동한다는 것을 알게됩니다.
내 질문은 ORM이 생각하는 것을 정말로 고려해야하는지 여부입니다. :) --- 아마도 관계가 진행될 것입니다. 어쨌든 데이터 저장소에 의해 시행되어야합니다. –
CodeFirst를 사용하면서 도메인 클래스에 따라 데이터베이스가 자동으로 생성됩니다. –
아, 알겠습니다. 음, * 문제가 될 수 있습니다. 분명히 나는 ORM을 명확히 할 수 없으므로 모든 ins-and-outs를 가진 것이 아니라는 것을 알았지 만,이 코드를 처음 들어 보았습니다 :) --- 참조 무결성을 설정할 수 없을 것입니다. 관계를 설정하지 않아도 코드 우선부터. 데이터베이스를 만든 후에 참조 무결성을 정의해야 할 수도 있습니다. 누군가가 멋진 EF 속임수를 안다면. –