Я занимался DDD уже пару лет, и до сих пор это сложно, когда дело доходит до разработки агрегатов. Это забавная часть DDD, от которой кружится голова. Я задаю этот вопрос, поскольку я архитектор в проекте, и мы находимся в процессе разработки модели. Это итерация, когда модель развивается параллельно с графическим интерфейсом и сбором требований вместе с заказчиком. Теперь к проблеме. Наш сценарий заключается в том, что мы сталкиваемся с некоторыми агрегатами, которые превращаются в очень большие AR. Я думаю, что хорошо нахожу объекты Value и избегаю ловушки анемичной модели предметной области. Но я никогда не был в такой ситуации. Одним из примеров является то, что наша система должна представлять антенну мобильной связи. Антенна расположена на зеленом поле. А вот антенна может иметь укрытие с оборудованием. Антенна может иметь микроволновую связь, может иметь оптоволокно в земле, может иметь радиоэлементы, может иметь источник питания. Лицом к лицу. Если Антенна отключена... все эти зависимости также удаляются. Так как они являются частью установки (кроме зеленого поля :)) Но Вы поняли. Модель антенны сложна... И большие AR не гибки в отношении блокировок параллелизма, производительности, потребления памяти.
После прочтения очень хорошей статьи Вона Вернона об эффективном дизайне дополненной реальности http://dddcommunity.org/library/vernon_2011/ Я понимаю, что нам нужно начать резать наши большие AR на куски.
Моя идея состоит в том, чтобы поступить так, как предлагает Вернон, переместить, например, MicrowaveLinks в отдельный AR (даже если это не так). Объект MicrowaveLink, теперь AR, является эталонной антенной по идентификатору. В классе MicrowaveLink Entity у нас есть свойство объекта значения, которое называется AntennaId. Наши варианты использования поддерживают этот сценарий. Мы редко перечисляем антенну и ссылки вместе. Таким образом, загрузка MicrowaveLinks возможна через MicrowaveLinkRepository.ListByAntenna(Guid антеннаId)
1) Делали ли вы этот AR-сплит раньше и как вы это делали? 2) Удалось ли вам поддерживать эту связь AR -> AR без изменений как с помощью ограничений домена, так и с помощью БД (мы используем EF 5 в качестве ORM)?
Моя оптимальная цель - пропустить коллекцию Antenna.Microwaves на антенне. Таким образом, антенна не знает, есть ли ссылки. Линки знают, на какой Антенне они установлены. И в объекте MicrowaveLink мне нужно только свойство AntennaId с, надеюсь, ограничениями БД, которые гарантируют, что антенна существует.
Мне известно, что я могу вручную добавить ограничения FK в методе Seed в EF или в БД напрямую через сценарии T-SQL. Но может ли эта взаимосвязь каким-то образом поддерживаться сопоставлением EF5 Code First Fluent?
