Управление конфигурацией Entity с ограниченным контекстом DDD

Question

Я пытаюсь реализовать несколько ограниченных контекстов DDD, как указано here. Это пример контекст:

У меня есть файл конфигурация типа объекта для каждого объекта с соответствующими отображениями FluentAPI (обратное проектирование с использованием EF инструментов). Эти файлы конфигурации также включают конфигурации отношений.

.: например UserMap.cs

// Relationships 
this.HasOptional(t => t.SecurityProfile) 
    .WithMany(t => t.Users) 
    .HasForeignKey(t => t.SecurityProfileCode); 

SecurityProfile и DomainPermission не в контексте DbSets. Они автоматически приводятся в модель из-за навигационных свойств на User и Module соответственно.

Это вызывает мою первую проблему. При добавлении User (или любой другой объект) в любом другом контексте я должен помнить, чтобы сделать одну из двух вещей:

1. добавить также конфигурации в модели строителя для SecurityProfile (и все другие отношения на предприятие)

2. Исключить SecurityProfile из модели явно как-то.

Это начинает немного кошмар для обслуживания.

Я был бы удовлетворен явно «обрезать» граф сущности, как указано в пункте 2 выше.

Однако не представляется возможным для объектов Ignore(), когда отношения уже определены в файлах конфигурации сущности.

Попытка modelBuilder.Ignore<SecurityProfile>(); для приведенного выше контекста OnModelCreating дает следующее сообщение об ошибке в ConfigureAssociations():

System.InvalidOperationException: Навигационная свойство «SecurityProfile» не является объявленное свойство по типу «Пользователь». Убедитесь, что он не был явно исключен из модели и что он является допустимым навигационным свойством.

Единственное решение, о котором я могу думать, это наследовать классы базовой конфигурации и переопределять конфигурацию отношений в каждом контексте. Учитывая, что мы можем закончиться 30-40 + отдельными контекстами, это также может стать кошмаром для обслуживания.

В качестве альтернативы я мог бы иметь очень конкретные модели сущностей для каждого контекста, но опять же это привело бы к взрыву класса объекта и потенциальной проблеме обслуживания в дублированной конфигурации.

Как я могу лучше управлять и поддерживать объекты и их конфигурации сущностей при реализации ограниченных контекстов?

Answer 1

Добавлен здесь из-за немного слишком долго для комментариев:

Крайне (не?) смешно отметить, что статья, на которую вы ссылаетесь, по-видимому, пытается прыгнуть на подножку, упоминая новое модное слово DDD и впоследствии демонстрируя только то, как объекты DTO/POCO могут сохраняться в контексте. Это не имеет ничего общего с DDD.

Проект, управляемый доменом, связан прежде всего с поведением и инкапсулированными (инфраструктурными изолированными/неосведомленными) моделями, которые итеративно исследованы и уточнены для решения конкретных проблем для конкретных участников и которые выражены в ubiquitous language проблемного домена.

Эти модели, как правило, не сопоставляются непосредственно с некоторыми типами моделей настойчивости, и они не должны быть связаны с этим. Операции, выполняемые по совокупным корням в ограниченном контексте, обычно выравниваются с границами транзакций.

Я бы посоветовал вам посмотреть некоторые из веб-трансляций Эрика Эвана о навыке (ключевое слово DDD eXchange), чтобы получить правильную перспективу относительно того, что подразумевает DDD, какие ограниченные контексты и общие корни. И после этого вы также действительно должны прочитать его книгу, это отличное чтение. Но вам нужны его более свежие перспективы (выраженные в этих веб-трансляциях), а не попадание в ловушку сосредоточения внимания на технологиях.