Мы должны использовать ограничения внешнего ключа при сохранении Моделей предметной области?

Думаю, да, я считаю, что это не столько для бизнес-логики, сколько для предотвращения попадания "плохих" данных в базу данных. Когда база данных станет очень большой, эти ограничения предотвратят головную боль в будущем.

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

Раньше я так думал, но мое мнение изменилось с тех пор, как я начал писать множество систем, ориентированных на ресурсы. Обычно для проверки части данных требуется гораздо больше, чем просто ограничения внешнего ключа - например, билет, который находится в статусе «назначено», должен иметь допустимое значение «назначено_то» и так далее. Все эти правила должны быть помещены в какую-либо процедуру проверки, и хотя теоретически может не повредить дополнительная проверка на уровне базы данных, если проверка на уровне приложения работает, проверка внешнего ключа ограничение - это просто потраченные впустую циклы. Что еще хуже, теперь у вас есть логика модели данных, повторяющаяся в двух местах - в коде проверки и в ограничениях базы данных.

Подумайте об этом так: хотели бы вы переместить в базу данных любую другую логику приложения (например, через хранимые процедуры), если бы вам не пришлось? Если бы вы не были вынуждены сделать это из соображений производительности, я думаю, что обычно ответ должен быть «нет».

Мне кажется, что игнорирование действительно полезных инструментов (целостность данных на уровне базы данных) ради чистой методологии разработки контрпродуктивно. Базы данных ДЕЙСТВИТЕЛЬНО хороши в таких вещах ... пусть они это делают.

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

«Моя первая реакция заключалась в том, что само использование реляционной базы данных подразумевает соблюдение таких ограничений, но некоторые утверждали, что база данных должна рассматриваться только как механизм устойчивости, и поэтому мы должны избегать помещая в него какую-либо бизнес-логику. Мы закончили тем, что не использовали ограничения внешнего ключа ».

Да, ну, посредственное большинство всегда побеждает в таких дебатах простой силой чисел, увы.

Если вы все еще хотите Чтобы вести эту битву, вы можете спросить своих оппонентов, как они намерены удерживать кого-либо от использования «прямых редакторов баз данных» (ala db2-aid, spufi, ...) и как они намерены удержать кого-либо от повреждения базы данных с помощью таких инструментов ( которые по определению обходят свои запрограммированные бизнес-ограничения).

Если вы хотите следовать парадигме дизайна, основанного на домене, то ответом будет «да» для чего-либо в рамках агрегата и «нет» для любых перекрестных агрегированных ссылок.

Почти во всех случаях, вы хотите, чтобы все, что находится под агрегированным корнем, удалялось при удалении самого корня, и поэтому наличие внешних ключей, представляющих это, с каскадным удалением, позволит вам добиться этого на уровне базы данных. Вы также можете настроить свои репозитории для каскадного удаления, если вы не хотите делать это на уровне БД, но точка все еще остается в том, что агрегированные дочерние элементы не должны существовать без корня.

По вопросам перекрестного агрегирования вы вероятно, будет заниматься бизнес-решениями относительно того, что должно произойти, когда то или другое будет удалено. Часто вы хотите иметь дело с этим асинхронно, чтобы обеспечить масштабируемость, и поэтому ваша модель предметной области в конечном итоге становится согласованной. Следовательно, в этих случаях не имеет смысла применять внешние ключи, так как будет промежуток времени, когда тот или иной ключ может не существовать.

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