Я много искал об ограниченном контексте, и я знаю, что это шаблон в Domain Driven Design, и он предназначен для деления нашей большой модели на более мелкие модели с использованием контекста базы данных, но это меня немного путает , на самом деле я не знаю, что именно он делает? и какие преимущества от использования этого шаблона
, пожалуйста, помогите мне разобраться в этом шаблоне.Ограниченный контекст в EntityFramework CodeFirst
Ограниченные контексты не обязательно должны ломать большую модель на более мелкие модели, а скорее для идентификации отдельных моделей доменов в вашем бизнесе. Каждый BC должен иметь свой собственный хранилище данных. BC может использовать данные из другого BC по-разному (слой антикоррупции, объекты ценности).
Таким образом, у вас может быть Asset BC, Warehousing BC, Invoicing BC, Accounting BC или CRM BC. Преимущество состоит в том, что вы можете сосредоточиться на одной области за раз. Вероятно, это довольно сложно понять, и определение границ требует глубокого знания различных доменов, поэтому эксперты по области неоценимы для достижения этой цели. Трудность находится на одном уровне с определением совокупных корней.
Большое преимущество заключается в том, что если вы получите развязку, то ваше обслуживание будет проще. Это правильная вещь :)
Ограниченный контекст возникает там, где один вездесущий язык является последовательным.
Ограниченная применимость конкретной модели. КОНЦЕПЦИИ КОНТРОЛЯ дает членам команды четкое и общее понимание того, что должно быть последовательным и что может развиваться независимо.
Прочитано this article, он дает полезную аналогию.
Я приведу пример, поскольку другие дали отличные объяснения.
Представьте, что вы сделали телефонный звонок в туристическое агентство, оператор в call-центре взял ваш звонок, он, вероятно, может ответить, начиная с «Дорогой мистер Доу» (представьте, что это имя вашего персонажа: John Doe) если вы звонили им раньше, и ваше имя было записано и привязано к вашему номеру телефона.
Через несколько секунд я позвонил в ту же туристическую организацию, оператор ответил «Дорогой мистер Чжоу».
МРС сказал оператору о наших фамилиях, но есть некоторые хитрый здесь: Я китайский, так что мое имя Чжоу hippoom (фамилия первый), но большинство западных имен Фамилия последний (John Doe ). Ради этого, CRM использует эту модель ниже:
Таким образом, оператор может определить фамилию клиентов напрямую, независимо от заказа.
С другой стороны, оператору понадобилось мое полное имя, когда я хотел забронировать авиабилет. Полное имя должно быть таким же, как в моем паспорте (чтобы я мог зарегистрироваться в аэропорту).Система бронирования воздуха использует ниже модель:
Есть два PersonName s в приведенном выше примере, вы можете использовать каноническую модель, конечно, но это просто не легко использовать для обоих из них:
1) использовать FullName в CRM позволяет оператору угадать, какой из них является фамилия
2) использовать фамилию/Firstname в бронировании воздуха не имеет смысла, потому что это не имеет значения до тех пор, пока они так же, как что в паспорте.
Ограниченный контекст конкретной модели работает лучше в этом случае: CRM.PersonName и AIR_BOOKING.PersonName
Кто-то сказал мне раньше: что-то не так легко использовать, если оно используется как родовое.
Джулия Лерман дает довольно хорошее объяснение ограниченного контекста.
Я рекомендую прочитать следующие http://msdn.microsoft.com/en-us/magazine/jj883952.aspx
Bounded контекст имеет много преимуществ, насколько архитектуры многоуровневых (с EF) обеспокоен:
Что такое «использование контекста базы данных»? И я не думаю, что ограниченный контекст привязан к определенной инфраструктурной технологии, такой как EntityFramework, не могли бы вы дать более подробную информацию? – Hippoom