Агрегаты, согласованность транзакций и Entity Framework DbContext

domain-driven-design ddd-repositories

724 просмотра

3 ответа

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

В наших реализациях репозитория мы используем Entity Framework для взаимодействия с реальной базой данных. Исторически у нас всегда были огромные контексты (охватывающие множество таблиц), которые представляют каждую доступную таблицу, поле и отношение в базе данных (или, по крайней мере, в некоторой функциональной области базы данных). Проблема в том, что этот контекст используется для сотен разных вещей и растет по экспоненте по мере того, как система становится больше, что приводит к чему-то, что очень трудно поддерживать.

Деление по ограниченному контексту

В связи с этим часто предлагается создавать отдельные DbContexts для каждого ограниченного контекста в системе. Джули Лерман предложила это в своей статье « Модели Shrink EF с DDD-ограниченным контекстом» .

Разделение по совокупности

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

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

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

  • В контексте должны существовать только таблицы, поля и взаимосвязи, необходимые для агрегата. Часто при работе с более широким контекстом вас не беспокоит большинство отношений или полей в данной таблице.

У этого подхода есть недостатки. А именно:

  • Хотя они, вероятно, будут смоделированы по-разному (в зависимости от их использования), определенные таблицы базы данных и отношения могут существовать в нескольких контекстах.

  • При использовании миграции кода сначала было бы сложно.

  • Это может рассматриваться как чрезмерное проектирование.

Кто-нибудь может дать дальнейшее понимание этого подхода? Возможно, я что-то упустил из виду?

РЕДАКТИРОВАТЬ:

Обратите внимание, что мы не используем объекты данных EF в нашем домене. Наши репозитории создают и гидратируют из этих объектов данных более богатую модель предметной области.

Автор: Dave New Источник Размещён: 12.11.2019 09:02

Ответы (3)


2 плюса

Я не рассматриваю контексты с несколькими агрегатами как проблему, особенно если вы следуете строгому разделению агрегатов - нет ссылок на сущности вне агрегата, только свободные коренные ссылки по ключу.

С другой стороны, я мог понять, зачем вам атомарные DbContexts, если вы точно знаете, что это узкое место в производительности.

Однако есть одна вещь: контексты EF не должны точно отображаться в ограниченные контексты на уровне домена. Если это произойдет, и вы попытаетесь максимально сократить контексты с обеих сторон, это может привести к повреждению IMO на уровне домена. Области BC могут потерять свою согласованность, и семантика важных вездесущих языковых понятий и подразделений может быть потеряна в процессе.

Автор: guillaume31 Размещён: 23.02.2015 10:34

1 плюс

Хороший вопрос - если вы используете EF в качестве доступа CRUD для реализации репозитория, а затем накладываете слои на самые богатые объекты DDD, то не ограничит ли ваш ограниченный контекст размер базовой схемы базы данных, используемой для сохранения всех сущностей, содержащихся внутри?

Если базовые таблицы и контекст EF огромны, я думаю, это будет означать, что ограниченный контекст может быть разбит дальше?

Полезная ссылка, которую я нашел с EF, находится здесь: http://mehdi.me/ambient-dbcontext-in-ef6/, когда у меня появилась действительно сложная схема EF, я пробовал разные приемы, но в конце концов поменял их вместо репозитория EventSourcing, но только где боль проекций и инфраструктуры стоила того, чтобы избежать миграций, объединения таблиц и т. д.

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

Мой совет - сохранять все в здравом уме и управляемым, придерживаясь ограниченных контекстов меньшего размера и не разделяя контексты / базы данных EF между ограниченными контекстами.

Вы можете обнаружить, что ограниченные контексты рефакторизируются и разделяются, есть определенные части, которые вы можете смоделировать как чистый CRUD-доступ напрямую к EntiyFramework, используя EF просто как ORM, напрямую к POCO, а затем к вашему прикладному уровню.

Автор: g18c Размещён: 23.02.2015 08:44

0 плюса

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

На мой взгляд, это очень плохая идея. Позвольте мне дать вам некоторые идеи.

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

Bounded Contextэто стратегический инструмент. Это дает границу моделирования, в которой можно создать решение для конкретной предметной области бизнеса . Внутри ограниченного контекста Ubiquitous Languageсформулирована команда. В рамках границы моделирования сигнатур команда может использовать любое количество полезных инструментов тактического моделирования, например Aggregates, EntitiesиValues Objects

Таким образом, наибольшее значение в применении DDD заключается в правильном определении ограниченного контекста. Это не просто теоретический артефакт. Разделение по совокупности приведет вас только к путанице и беспорядку. Вы не сможете четко определить, к какой проблеме домена вы обращаетесь.

С другой стороны , вы можете использовать только тактические модели , как Aggregates, Entitiesи , Values Objectsно это не домен Driven Design.

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

Как ? Я не могу получить это. Для меня это создало бы больше беспорядка. Интеграция ограниченного контекста осуществляется с помощью, Anti corruption layersкоторый защищает вас от изменений извне. Ограниченный контекст может развиваться независимо от других. Если вы хотите больше узнать о том, как происходит интеграция между ограниченным контекстом с стратегической точки зрения, пожалуйста, посмотрите Context mapping.

Хотя они, вероятно, будут смоделированы по-разному (в зависимости от их использования), определенные таблицы базы данных и отношения могут существовать в нескольких контекстах. При использовании миграции кода сначала было бы сложно. Это может рассматриваться как чрезмерное проектирование.

При выполнении Domain Driven Design вы не определяете свой выбор, основываясь на технических ограничениях, особенно на платформе ORM.

Идти дальше:

Время от времени агрегат может иметь отображение 1: 1 с ограниченным контекстом. Но это зависит от бизнес-проблемы, а не от технического решения.

Дизайн, управляемый доменом, не прост в применении без более глубокого понимания. Иногда вашему домену это действительно не нужно, поэтому нет смысла пытаться навязать его вашей конкретной проблеме.

В заключение я бы остановился на предложении, сделанном в статье Джулии Лерманн.

Автор: Tomasz Jaskuλa Размещён: 19.03.2015 11:52
Вопросы из категории :
32x32