Одной из самых больших проблем, приближенной к теме Domain Driven Design является большое количество новых идей, моделей и терминов, которые необходимо понимать.
Это часто может означать, что тема неприступна или подавляющая, потому что вы чувствуете, как вы тонете в большом количестве информации.
Прошлый раз мы рассматривали Domain Model, что это значит и как думать о нем как о части приложения.
На этот раз мы собираемся рассмотреть еще две части: терминологию Domain Driven Design в ограниченных контекстах и контексте Maps.
Что такое Domain Model?
Domain Model – это структурированные знания, которые связаны с конкретной проблемой. Domain Model может быть кодом, прозой или схемой.
Domain model фокусирует свое внимание на конкретной задаче. Это ограничение позволяет вам быть в центре проблемы игнорируя все, начиная от внешнего мира.
Если вы новичок в Domain Model, рекомендую прочитать предыдущий пост, прежде чем продолжить с этим.
Реальный мир существующих Domain Models
Теоретическая идея Domain Model имеет много смысла в мире программирования. Domain Model является целенаправленным знанием проблемы и таким образом,то, что вы имеете четкое представление проблемы и ее решение, делает вашу жизнь в качестве программиста намного проще.
Иметь единую модель — это замечатльная цель, потому что единую унифицированную модель, в теории, легче понять.
Тем не менее, в реальном мире создания приложений для бизнеса, не бывает только одной Domain Model. Если вы создаете приложение, которое затрагивает многие части существующего бизнеса, вы, вероятно, столкнетесь с несколькими сосуществующими моделями, которые часто противоречат друг другу.
Например, в типичной электронной коммерции веб-приложения, термин Product в системе учета будет, вероятно, означать что-то другое, чем на витрине магазинов. Это может означать, что две разные системы имеют две разные идеи ответственности за этим объектом, или что объект должен иметь два совершенно разных набора возможностей.
Когда объекты имеют несколько разные обязанности в различных частях приложения, они могут стать монолитными и с ними будет трудно работать. Когда есть несколько разработчиков, работающих над различными проблемами, используя те же самые объекты, то противоречивые требования, непредвиденные ошибки и несоответствия неизбежны.
Domain Model должна сосредотачивать знания вокруг конкретной проблемы. Это ограничивает сферу применения Domain Model в очень специфическом контексте. Когда вы столкнулись с этими противоречивыми идеями, самое сделать шаг назад от Domain Model.
Что такое ограниченный контекст (Bounded Context)?
Ограниченный контекст (bounded context)– это граница, которая окружает ту или иную модель. Это держит знания внутри соответствующей границы, в то же время игнорируя помехи от внешнего мира.
Это выгодно по ряду причин.
Во-первых, вы можете моделировать различные аспекты проблемы не контактируя с другими частями бизнеса. Используя предыдущий пример, объект Product в рамках складской системы должен быть связан с помощью методов и свойств этой единой системы, а не какой-либо другой коммерческой фирмы, что случается когда пытаются соответствовать объекту под названием Product.
Во-вторых, терминология в ограниченном контексте(Bounded Context) может иметь одно, четкое определение, что точно описывает конкретную проблему. Различные отделы по всей компании, как правило, имеют немного разные идеи и определения аналогичных условий, это часто может сорвать проект из-за отсутствия ясности и понимания, если сроки являются неоднозначными.
Что такое контекст Maps?
Когда вы начинаете думать о различных подсистемах приложения как о индивидуальных ограниченных контекстах (bounded context), вы можете потерять из виду глобальную концепцию бизнеса в целом.
Это неизбежно, что различным ограниченным контекстам( bounded context) приложения нужно будет общаться или делиться данными друг с другом.
Контекст Maps — это глобальный взгляд на приложения в целом. Каждый ограниченный контекст(Bounded Context) вписывается в контекст Maps, чтобы показать, как они должны взаимодействовать между собой и какие данные должны быть общими.
Заключение
Ограниченный контекст (bounded context) является очень важным инструментом моделирования, когда дело доходит до Domain Driven Development.
Ограниченные контексты (bounded context) позволяют разделить большую проблему на гораздо меньшие, так что вы cможете сосредоточиться на конкретных аспектах приложения, в то же время игнорируя все остальное.
Это позволяет сформировать единый язык вокруг этой конкретной проблемы, так что каждый человек имеет четкое определение каждого из важных терминов.
Обычно существуют определенные объекты в веб-приложении, которые имеют разные определения в разных контекстах приложения. Разделив приложение на ограниченные контексты ( bounded context), вы убедитесь, что линии между каждым контекстом четко разграничены так, чтобы терминология вокруг идей и концепций приложения была ясной.