Что, по отношению к DDD, является ограниченным контекстом?

Работая с книгой Вона Вернона «Внедрение доменного дизайна», я не смог понять, что такое ограниченный контекст на самом деле.

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

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

Мартин Фаулер кратко обсуждает идею ограниченного контекста ( http://martinfowler.com/bliki/BoundedContext.html ), но на самом деле не проясняет проблему.

В конце концов, что такое ограниченный контекст? Это группировка поддоменов? Модель и язык для поддоменов? Реализация поддоменов? Без этих ответов довольно сложно понять, как разложить реальное проблемное пространство на ограниченные контексты.

Ограниченные контексты и субдомены существуют на разных уровнях.

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

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

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

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

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

Поскольку телепатия все еще находится в зачаточном состоянии, эти идеи передаются между людьми с использованием слов и фраз.

Слова и фразы могут быть неоднозначными в лучшие времена. Чтобы помочь нам уменьшить двусмысленность, мы используем «контекст», чтобы прояснить их значение.

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

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

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

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

Это какое-то явное подтверждение со стороны команды, что именно this phraseв this part of the projectсредствах this thing(а не, как вы могли бы подумать that thing).

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

Вот и все. Это очень простая идея, которая так важна, что о ней написано много.

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

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

Но да. Мир не так прост.

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

Кроме того, вещи взаимодействуют с другими вещами, и ограниченные контексты также должны взаимодействовать друг с другом. Таким образом, существуют различные модели для описания того, как происходят эти взаимодействия. См. Книгу Эрика Эвана «Управление через домен», глава 14, по этим различным шаблонам: общее ядро, поставщик клиента, конформист, антикоррупционный уровень, отдельные пути, служба открытого хоста, опубликованный язык.

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

В разных ситуациях я использую три разные точки зрения или метафоры концепции ограниченного контекста.

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

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

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

Мне очень нравится этот пример концепции ограниченного контекста.

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