Должна ли быть установлена ​​одна или отдельная база данных для каждого ограниченного контекста для каждой базы данных?

Question

В DDD, насколько я понимаю, это помогает или помогает вам структурировать сложное приложение. Теперь в приложении вы должны определить свой ограниченный контекст. Скажем, у вас более 10 до н.э.

Я где-то читал (простите, я не могу дать никаких ссылок), что его не идеально, чтобы иметь 1-большую базу данных для сложного приложения. Чтобы он был отделен для каждого ВС. Если это более простой путь. Как создать структуру приложения, если каждая БК имеет свою собственную базу данных.

Я пробовал искать на github, но не могу найти.

Answer 1

Это зависит немного от причины, по которой они являются их собственной базой данных. Идея ограниченного контекста заключается в том, что у вас есть набор сущностей, которые связаны друг с другом и совместно решают проблему. если вы посмотрите на ссылку Chaim Eliyah при условии, что у вас могут быть продажи и контекст поддержки. http://martinfowler.com/bliki/BoundedContext.html

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

Этим субъектам все равно, где они хранятся. Если у вас уже есть огромная база данных продукта, вы можете, конечно, создать свои сущности для разных ограниченных контекстов на основе той же базы данных. Следует помнить, что таблица базы данных не совпадает с сущностью. Объекты - это то, что нужно вашему бизнесу/приложению. База данных - это то, что нужно для хранения вещей.

Это, отдельный если возможно. Если это невозможно, попробуйте определить владельцы. Вы делаете свою жизнь намного легче, если все согласны с тем, что продукт является продуктом, определенным по продажам, и эта поддержка может иметь «productfactsheetTable», дополняющий продукт. Таким образом, вы избегаете противоречивых изменений в каждом ограниченном контексте. (также следует, что поддержка может читать только продукты, но никогда не писать). Табличные префиксы могут помочь здесь сделать это ясно.

И эта проблема уже существует с 2 связанным ограниченным контекстом. К 10 у вас будет кошмар, если несколько контекстов попытаются записать в ту же таблицу.

Answer 2

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

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

Если вы располагаете большой базой данных (здесь вы говорите о корпоративном программном обеспечении, поэтому в дикой природе не будет много примеров), то соблазн состоит в том, чтобы обойти всю экспертизу домена, которая была захвачена в доменах, и meddle в другой базе данных BC. Вещи становятся большим мячом грязи очень быстро.

Удивительно, но я вижу такое явление слишком часто в реальном мире, и я считаю это очень плохой практикой.

Answer 3

Это зависит от того, есть ли у них только одна и та же база данных, а также некоторые таблицы - т. Е. Данные.

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

я вижу еще несколько недостатков в базу данных таблицы разделяют 2 или более ограниченной контексты:

• тесная связь. Причина, по которой мы имеем отчетливое БК, состоит в том, что они представляют собой различные доменные пространства, которые могут расходиться по-своему. Изменение концепции в одном из BC может повлиять на базовую таблицу, заставив другие BC, которые используют эту таблицу, также измениться. Вы получаете жесткость, где должна быть гибкость. У вас могут быть также несоответствия или «дыры» в данных из-за множества возможных источников изменений.

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

• ORM доброжелательность. Большинство ORM не позволят вам отображать 2 или более классов из одной таблицы базы данных без большого количества сверток и обходных путей.

Как следует одна структуры приложения, если каждый Британской Колумбии своих собственной базы данных.

В какой-то степени (например, это может быть слой UI или нет), как если бы у вас было несколько отдельных приложений. Пожалуйста, будьте более конкретными, если у вас есть четкие вопросы.