Проектирование на основе доменов - проблема с общим корневым дизайном

Question

Я сейчас занимаюсь рефакторингом системы.

У меня следующая ситуация:

Система предназначена для предоставления информации о компаниях в нескольких секторах бизнеса. Каждая компания может работать в одном или нескольких секторах. Компании могут участвовать в определенных партнерских программах. Компания может иметь одного или нескольких производителей-партнеров (например, гараж может иметь партнерские отношения с BMW / Mercedes) и т. Д. Все эти участия существуют в определенный период времени (период действия). Кроме того, такой производитель, как BMW, связан с одним бизнес-сектором. Таким образом, компания может быть партнером BMW, только если BMW действительна для бизнес-сектора компаний. То есть, потому что система обслуживает не только компании такого сектора, как гаражи, но и услуги буксировки и т. Д.

Так что сейчас мой дизайн может вызвать некоторые инварианты.

Компания -> Назначение (не меняется медленно) -> Сектор бизнеса

Компания -> Партнерство (дата от - до) -> Организация <- Сектор бизнеса </p>

В тех случаях, когда Компания и Организация должны совместно использовать одно и то же назначение в бизнес-секторе.

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

Как бы вы смоделировали что-то подобное?

Answer 1

Я вижу 2 DDD-совместимых способа применения этого бизнес-правила:

• DDD указывает , что инварианты в Агрегате должны принудительно применяться корнем Агрегирования.Если компания является вашим сводным корнем, то при добавлении в нее нового партнерства она может проверить, соответствует ли партнерство правилу бизнес-сектора (возможно, с использованием шаблона Спецификация : например, ElptableForPartnershipSpecification)

• При изменении бизнес-сектора организации рекомендуется подумать о "можно ли выполнить операцию?"а не «действительна ли эта сущность?» .Это может означать проверку наличия у Компании в репозитории Компании Партнерства, которое станет непоследовательным после модификации, и решить, что делать (возможно, на основе шаблона политики / стратегии).

Контракты - это еще один разумный способ применения инвариантов: см. http://msdn.microsoft.com/en-us/magazine/hh205755.aspx (.NET)

Answer 2

Что-то идет не так в вашем объяснении.В этом дизайне нет общих корней.

Но логически, вероятно, следующие утверждения противоречат

Производитель, такой как BMW, связан с одним бизнес-сектором (1)

и

можно изменить присвоение бизнес-сектора Организации (2)

Если это так, вы должны избегать одного из них.

Если (2) неверно, товсе хорошо, верно?Вы просто не допускаете такое изменение.

Если (1) является ложным (или, скорее, не таким уж ограничительным), то границы организации с бизнес-сектором также должны быть ограничены определенным периодом времени.В этом случае вы делаете это таким же образом, как ограничение срока партнерства.

Например, вы можете установить Partnership.EndDate на дату изменения ссылки «Организация-> Сектор».

Кроме того, вы можете вести некоторый исторический список Секторов, в которых участвовала Организация. Бизнес-правила будут предусматривать совпадение периодов для Партнерства и назначения Секторов.

Надеюсь, что это поможет.(А на самом деле общие вопросы по дизайну должны быть на сайтах программистов .)