Эта книга является второй профессиональной книгой, которую я прочитал после окончания учебы. Первая книга, которую я только что прочитал на работе, учила, как сделать конкретные реализации более элегантными на уровне кода. Эта книга направлена на улучшение возможностей абстракции, дизайна верхнего уровня и возможностей моделирования предметной области. . В процессе чтения книга ответила на многие недоразумения в предыдущей работе, например, как определить границы между командами и модулями проекта? Есть ли хороший способ вывести код проекта из все более неконтролируемого финала? Кроме того, что еще более важно, в процессе чтения книг мы не должны ограничивать свои размышления о содержании самим произведением, содержащиеся в нем идеи могут полностью направлять, как моделировать проблемы в области жизни и ощутить новизну и красоту жизнь. В книге много резонансов и много содержания.Из-за отсутствия опыта работы у меня нет глубокого понимания этого.В настоящее время я еще мало вникаю в суть этого памятника.Жду с нетерпением продолжая подтверждать и выяснять вещи в книге в последующей работе и жизни, и поощрять всех!
Часть 1. Использование модели предметной области
1. Какова роль моделей в предметно-ориентированном проектировании?
- Взаимодействие модели и дизайна
- Модель является основой общего языка, используемого всеми членами команды: благодаря связи между моделью и реализацией разработчики могут использовать этот язык для обсуждения программ.
- Модели — это сжатые знания
2. Ядро софта?
В основе программного обеспечения лежит его способность решать проблемы пользователей, связанные с предметной областью. Все остальные функции, какими бы важными они ни были,
служат этой основной цели.
3. Привязка модели и реализации
Если программное обеспечение разрабатывается без концепций, тогда программное обеспечение в лучшем случае представляет собой механизированный продукт,
выполняющий полезные функции без объяснения того, почему он работает.
Если весь дизайн программы или ее основная часть не соответствует модели предметной области, то модель бесполезна и корректность программного обеспечения вызывает сомнения. В то же время слишком сложное соответствие между функциями модели и конструкции трудно для понимания, а в
реальных проектах невозможно сохранить эту связь при изменении конструкции. Если существует серьезное расхождение между анализом и проектированием, то знания, полученные в ходе анализа и проектирования, не могут быть переданы друг другу .
Дизайн каждой части программной системы должен точно отражать модель предметной области, чтобы отражать четкое соответствие между ними. Модели следует многократно проверять и модифицировать, чтобы программное обеспечение реализовывало их более естественно, даже если они пытаются отразить более глубокие концепции предметной области. Нужная нам модель должна не только удовлетворять этим двум требованиям, но и поддерживать надежный ВСЕГДА ЯЗЫК (универсальный язык). Терминология для разработки программы и распределения основных обязанностей вытекает из модели. Пусть программный код является выражением модели, а изменения в коде могут быть изменениями в модели. И его воздействие обязательно повлияет на следующую соответствующую проектную деятельность. Реализации, которые полностью полагаются на модели, обычно требуют средств разработки программного обеспечения и языков, поддерживающих парадигмы моделирования, такие как объектно-ориентированное программирование.
4. Почему модели важны для пользователей?
Когда программа разрабатывается на основе модели, отражающей основные интересы пользователей и экспертов в предметной области, такой дизайн может передать пользователям ее намерения более четко, чем это можно было бы сделать в противном случае. Предоставление пользователям возможности понять модель даст им больше возможностей
для использования потенциала программного обеспечения, а также сделает поведение программного обеспечения разумным и последовательным.
- HANDS-ON MODELER (модельер-практик)
Если люди, которые пишут код, не думают, что несут ответственность за модель, или не знают, как заставить модель служить приложению, то модель не имеет ничего общего с программой. Если разработчики не осознают, что изменение кода означает изменение модели, их рефакторинг программы не только укрепит модель, но и ослабит ее. Аналогично, если разработчик модели не участвует в процессе реализации программы, то ограничения реализации программы лично не будут ощущаться, а если и будут, то быстро забудутся. Один из двух основных элементов ПРОЕКТИРОВАНИЯ НА МОДЕЛИ (то есть модель должна поддерживать эффективную реализацию и абстрактное знание ключевой предметной области) был утерян, и окончательная модель больше не станет практичной. Наконец, если разделение труда блокирует сотрудничество между дизайнерами и разработчиками, так что они не могут передать детали реализации ПРОЕКТИРОВАНИЯ, УПРАВЛЯЕМОГО МОДЕЛЯМИ, то опытные дизайнеры не могут передать свои знания и технологии разработчикам.
Любой технический специалист, участвующий в моделировании, независимо от его основной ответственности за проект, должен уделить время для понимания кода. Любой, кто отвечает за изменение кода, должен научиться выражать модель в коде. Каждый разработчик должен в той или иной степени участвовать в обсуждении модели и поддерживать контакт с экспертами в предметной области. Люди, занятые на разных работах, должны своевременно и осознанно обмениваться идеями о моделях с теми, кто прикасается к коду через ВЕЗДЕСЯ ЯЗЫК.
Часть II Составные блоки проектирования на основе моделей
1. Почему существует многоуровневая архитектура?
В объектно-ориентированных программах вспомогательные коды, такие как пользовательский интерфейс и доступ к базе данных, часто пишутся непосредственно в бизнес-объектах. И некоторая бизнес-логика будет встроена в компоненты пользовательского интерфейса и сценарии базы данных. Это делается для того, чтобы завершить разработку в кратчайшие сроки.
Просмотр и анализ кода домена может стать чрезвычайно трудным, если код, относящийся к домену, разбросан среди большого количества других кодов. Простые модификации пользовательского интерфейса, скорее всего, действительно изменят бизнес-логику, а корректировка бизнес-правил, вероятно, потребует тщательной проверки кода пользовательского интерфейса, кода операций базы данных или других элементов программы. Это снижает вероятность получения согласованных объектов, управляемых моделями, и затрудняет автоматизированное тестирование. Учитывая огромное количество логики и технологий, задействованных в различных действиях программы, сама программа должна быть простой и понятной, иначе она будет непонятна.
Сложные сложные приложения. Проектируйте каждый слой отдельно, чтобы он был связным и зависел только от слоев под ним. Примите стандартные архитектурные шаблоны и лишь слабо соедините их с верхним слоем. Поместите весь код, связанный с моделью предметной области, в один слой и отделите его от кода пользовательского интерфейса, приложения и инфраструктуры. Объекты предметной области должны сосредоточиться на том, как выразить модель предметной области, не принимая во внимание собственные проблемы отображения и хранения, а также не управляя задачами приложения и т. д. Это делает модель достаточно осмысленной и достаточно структурированной, чтобы фиксировать необходимые бизнес-знания и эффективно их использовать.
2. SMART UI «анти-шаблон»
Если неопытная проектная группа хочет выполнить простой проект, но решает использовать ДИЗАЙН, УПРАВЛЯЕМЫЙ МОДЕЛЯМИ, и СЛОЕВУЮ АРХИТЕКТУРУ, то проектная группа пройдет сложный процесс обучения. Участникам команды пришлось осваивать сложные новые технологии и на собственном горьком опыте изучать объектное моделирование. (Даже с помощью этой книги это по-прежнему сложная задача!) Управление инфраструктурой и слоями делает выполнение простой задачи занимающей много времени. Простые проекты имеют более короткие циклы разработки и более низкие ожидания. Таким образом, проект будет закрыт задолго до того, как проектная группа сможет выполнить задачу, не говоря уже о демонстрации многих захватывающих возможностей этого подхода.
Даже имея больше времени на проекте, члены команды с меньшей вероятностью освоят эти методы без помощи экспертов. В конце концов, если им удастся преодолеть эти трудности, они, вероятно, разработают только простую систему. Потому что этому проекту не нужны богатые возможности.
поэтому:
Реализуйте всю бизнес-логику в пользовательском интерфейсе. Разделите прикладную программу на небольшие функциональные модули, соответственно внедрите их в пользовательский интерфейс и встройте в него бизнес-правила. Используйте реляционную базу данных в качестве общего репозитория данных. Используйте самые автоматизированные средства создания пользовательского интерфейса и средства визуального программирования.
3. Модель, представленная в программе?
- Ассоциация : Каждая проходимая ассоциация в модели должна иметь один и тот же механизм атрибутов в программном обеспечении.
- ENTITY : Некоторые объекты не определяются в первую очередь своими атрибутами. На самом деле они представляют собой «Нить идентичности» (Нить идентичности), которая охватывает время и часто подвергается множеству различных представлений. Иногда такой объект необходимо сопоставить с другим объектом с другими свойствами. А иногда объект необходимо отличать от другого объекта с теми же свойствами. Неправильная идентификация может привести к повреждению данных. Объекты, в первую очередь определяемые идентификатором, называются СУЩНОСТЬЮ.
- ОБЪЕКТ ЗНАЧЕНИЯ : объект, используемый для описания аспекта домена без концептуальной идентичности, называется ОБЪЕКТОМ ЗНАЧЕНИЯ (объектом значения). После создания экземпляра VALUEOBJECT он используется для представления некоторых элементов дизайна.Для этих элементов дизайна нас интересует только то, что они собой представляют, а не
кто они. - СЛУЖБА : Иногда объект не является вещью. В некоторых случаях самый четкий и практичный проект будет включать специальные операции, которые концептуально не принадлежат какому-либо объекту. Вместо того, чтобы загонять их в одну категорию, лучше естественным образом ввести в модель новый элемент — СЕРВИС (сервис).
Когда важный процесс или операция преобразования в домене не является естественной обязанностью ENTITY или VALUE OBJECT, операция должна быть добавлена в модель как независимый интерфейс и объявлена как SERVICE. Используйте модельный язык при определении интерфейсов и убедитесь, что имена операций являются терминами ВСЕГДА ЯЗЫКА. Кроме того, СЛУЖБА должна быть безгражданской.
- МОДУЛЬ: : МОДУЛЬ предоставляет людям два способа наблюдения за моделью: один — просматривать детали в МОДУЛЕ, не отвлекаясь на всю модель, а другой — наблюдать взаимосвязь между модулями, не рассматривая ее внутренние детали. Модули описывают домен с более широкой точки зрения.
Модули используют все, но мало кто видит в них полноценную часть модели. Код разбит на различные категории, иногда в соответствии с технической архитектурой, а иногда в соответствии с разделением задач разработчика. Даже те разработчики, которые много занимаются рефакторингом, склонны использовать некоторые модули, сформированные в начале проекта.
Как мы все знаем, должна быть низкая связь между модулями, но высокая связность внутри модуля. Интерпретации связи и сцепления заставляют МОДУЛЬ звучать как технический индикатор, как будто судя о них механически на основе распределения ассоциаций и взаимодействий. Однако МОДУЛЬ — это не только разделение кода, но и разделение концепций. Вещи, которые человек рассматривает в одно время, ограничены (отсюда и необходимость низкой связанности). Бессвязные мысли так же трудно понять, как и мысли «каши из одной кастрюли» (отсюда и высокая связность).
поэтому:
Выберите модуль, который может описывать систему и включать связный набор концепций. Обычно это приводит к слабой связи между модулями, но если это не идеально, следует искать способ изменить модель, чтобы устранить связь между концепциями, или найти концепцию, которую можно использовать в качестве основы для модуля (эта концепция могли быть упущены из виду раньше.), модули, организованные вокруг этой концепции, могут группировать элементы вместе осмысленным образом. Найдите слабосвязанный способ организации понятий, чтобы их можно было понять и проанализировать независимо друг от друга. Модель уточняется до тех пор, пока ее можно будет разделить в соответствии с концепциями предметной области высокого уровня без привязки соответствующего кода.
Имя модуля должно быть термином на ВСЕЯЗЫЧНОМ ЯЗЫКЕ. Модули и их названия должны отражать глубокие знания предметной области.
4. Жизненный цикл объектов предметной области
1. АГРЕГАТ
Нам нужно использовать абстракцию для инкапсуляции ссылок в модели. АГРЕГАТ — это набор связанных объектов, мы
рассматриваем его как единицу модификации данных. У каждого АГРЕГАТА есть корень (корень) и граница (граница). Границы определяют, что находится внутри АГРЕГАТА. Корень — это конкретная СУЩНОСТЬ, включенная в АГРЕГАТ. Для AGGREGATE внешние объекты могут ссылаться только на корень, а объекты внутри границы могут ссылаться друг на друга. СУЩЕСТВА, отличные от корневого, имеют локальные идентификаторы, но эти идентификаторы нужно различать только внутри АГРЕГАТА, потому что внешние объекты не могут видеть другие объекты, кроме корневого СУЩНОСТИ.
Мы должны собрать СУЩНОСТЬ и ОБЪЕКТ ЗНАЧЕНИЯ в АГРЕГАТ по категориям и определить границы каждого АГРЕГАТА. В каждом АГРЕГАТЕ выберите СУЩНОСТЬ в качестве корня и контролируйте весь доступ к другим объектам в пределах границы через корень. Только внешним объектам разрешено сохранять ссылки на корень. Временные ссылки на внутренние члены могут передаваться, но только для одной операции. Поскольку доступ контролирует корень, его нельзя обойти для изменения внутренних объектов. Этот дизайн полезен для обеспечения того, чтобы объекты в АГРЕГАТЕ удовлетворяли всем фиксированным правилам, а также чтобы АГРЕГАТ в целом удовлетворял фиксированным правилам при любом изменении состояния.
2. ЗАВОД
Создание объекта само по себе может быть крупной операцией, но создаваемые объекты плохо подходят для сложных операций сборки. Смешение этих обязанностей может привести к плохому пониманию дизайна. Возложение на клиента прямой ответственности за создание объектов портит дизайн клиента и нарушает инкапсуляцию собранного объекта или АГРЕГАТА, а также приводит к слишком тесной связи между клиентом и реализацией создаваемого объекта.
За создание сложных объектов отвечает уровень предметной области, однако эта задача не относится к объектам, используемым для представления модели.
поэтому:
Ответственность за создание экземпляров сложных объектов и AGGREGATE должна быть переложена на отдельный объект, который сам по себе может не нести ответственность в модели предметной области, но который все же является частью дизайна предметной области. Обеспечьте интерфейс, который инкапсулирует все сложные операции сборки, и этот интерфейс не требует, чтобы клиенты ссылались на конкретный класс объекта, который должен быть создан. Создайте АГРЕГАТ в целом и убедитесь, что он удовлетворяет установленным правилам.
3. ХРАНИЛИЩЕ
Целью проектирования, ориентированного на предметную область, является создание лучшего программного обеспечения путем сосредоточения внимания на модели предметной области, а не на технологии. Предположим, что разработчик создает SQL-запрос и передает его определенной службе запросов на уровне инфраструктуры, а затем извлекает требуемую информацию в соответствии с результирующим набором полученных данных строки таблицы и, наконец, передает информацию конструктору или FACTORY. Когда разработчики выполняют эту серию операций, модель перестает быть в центре внимания. Мы, естественно, рассматриваем объекты как контейнеры для хранения запрошенных данных, поэтому весь дизайн сводится к стилю обработки данных. Хотя точные технические детали отличаются, проблема остается — клиент имеет дело с технологией, а не концепцией модели.
Клиентам нужен эффективный способ получения ссылок на существующие объекты предметной области. Если бы инфраструктура предоставляла такую возможность, разработчики могли бы добавить множество проходимых ассоциаций, которые сильно загромождали бы модель. С другой стороны, разработчики могут использовать запросы для извлечения необходимых им данных из базы данных или для непосредственного извлечения определенных объектов, а не для получения этих объектов через корень АГРЕГАТА. Это приводит к тому, что доменная логика переходит в запрос и клиентский код, а ENTITY и VALUE OBJECT становятся простыми контейнерами данных. Принятие большей части технической сложности обращения с доступом к базе данных быстро приводит к загромождению клиентского кода, что заставляет разработчиков упрощать уровень предметной области и в конечном итоге делает модели неактуальными.
Случайные запросы к базе данных могут нарушить инкапсуляцию объектов домена и AGGREGATE. Незащищенность технической инфраструктуры и механизмов доступа к базам данных усложняет работу клиентов и препятствует
проектированию на основе моделей.
Предоставляйте РЕПОЗИТОРИЙ только для тех ОБЪЕДИНЕННЫХ корней, которые действительно нуждаются в прямом доступе. Пусть клиенты всегда сосредотачиваются на модели и оставляют все операции хранения объектов и доступа к РЕПОЗИТОРИЮ.
5. Как вы моделируете менее очевидные концепции?
- Отображаемые ограничения: абстрагируйте детали ограничений отдельно, а затем явно выражайте концепцию
- Смоделируйте процесс как предметный объект: ограничения и процессы — это два основных типа понятий модели.Объекты используются для инкапсуляции процессов, так что нам нужно только учитывать бизнес-цель или намерение объекта. На самом деле типичным является шаблон стратегии, который мы часто используем.
- СПЕЦИФИКАЦИЯ: Инкапсулируйте правила, интерфейс явно выражает правила и облегчает тестирование правил.
Третья часть углубляет понимание посредством рефакторинга
Много чрезмерной инженерии становится правдоподобным во имя гибкости. Однако слишком много слоев абстракции и косвенного дизайна часто становятся камнем преткновения для проектов. Посмотрите на дизайн программного обеспечения, которое на самом деле дает пользователю огромную силу, и вы часто найдете что-то простое. Простое сделать не просто.
Слушайте язык, на котором говорят эксперты в предметной области. Есть ли термины, которые лаконично выражают сложные понятия? Исправили ли они вашу формулировку (может быть, тактичное напоминание)? Убрали ли они недоумение на лице, когда вы используете те или иные словесные выражения? Все это намекает на понятие, которое могло бы улучшить модель.
1. ИНТЕРФЕЙСЫ, ВЫЯВЛЯЮЩИЕ НАМЕРЕНИЯ
Если разработчик должен изучить его реализацию, чтобы использовать компонент, то значение инкапсуляции теряется. Когда объект или операция, разработанная кем-то, используется другими, если новый разработчик, который использует этот компонент, должен сделать вывод о его использовании на основе его реализации, то то, что он делает вывод, может не быть основной целью этой операции или класса. Если этот компонент предназначен не для этого, то пока код работает, но концептуальная основа дизайна была использована неправильно, и намерения двух разработчиков разошлись.
2. ФУНКЦИЯ БЕЗ ПОБОЧНЫХ ЭФФЕКТОВ
Результаты взаимодействия или комбинации вычислений нескольких правил трудно предсказать. Когда разработчик вызывает операцию, чтобы предсказать результат операции, он должен понимать ее реализацию и реализацию других вызываемых ею методов. Если разработчик должен «снять завесу с интерфейса», абстракция интерфейса ограничена. Без абстракций, результаты которых можно с уверенностью предвидеть, разработчики должны ограничивать «комбинаторный взрыв»1, ограничивающий богатство поведения системы.
Поэтому :
Максимально поместите логику программы в функции, потому что функции — это операции, которые возвращают только результаты без очевидных побочных эффектов. Строго изолируйте команды (методы, вызывающие очевидные изменения состояния) до очень простых операций, которые не возвращают информацию о домене. Когда вы найдете концепцию, которая очень подходит для выполнения сложных логических задач, вы можете переместить эту сложную логику в ОБЪЕКТ ЗНАЧЕНИЯ, который может дополнительно управлять побочными эффектами.
3. УТВЕРЖДЕНИЕ
Если бы побочные эффекты операций только неявно определялись их реализацией, причина и следствие превратились бы в беспорядок в системе с большим количеством взаимосвязей между вызовами. Единственный способ понять программу — проследить за ее выполнением по путям ветвления. Инкапсуляция полностью теряет свое значение. Отслеживание конкретных казней также делает абстракцию бессмысленной.
Поэтому :
Ясно выразите постусловия операции и фиксированные правила класса и АГРЕГАТА. Если УТВЕРЖДЕНИЯ не могут быть написаны непосредственно на вашем языке программирования, напишите их как автоматизированные модульные тесты. Их также можно записывать в документы или диаграммы (если это соответствует стилю разработки проекта).
Ищите модели, которые концептуально связны, чтобы разработчикам было легче рассуждать об ожидаемых УТВЕРЖДЕНИЯХ, тем самым ускоряя процесс обучения и избегая несоответствий кода.
4. ПОНЯТИЙНЫЙ КОНТУР
Если все элементы модели или конструкции разместить в общей более крупной структуре, их функции будут дублироваться. Внешний интерфейс не может предоставить всю информацию, которая может быть интересна клиенту. Поскольку разные понятия смешиваются вместе, их значение становится трудно понять.
С другой стороны, также может быть бессмысленно разбивать классы и методы, что усложнит клиент и заставит клиентский объект понять, как различные части сочетаются друг с другом. Хуже того, некоторые понятия могут быть полностью утеряны. Половина атомов урана не является ураном. Более того, размер детализации — не единственный вопрос, который необходимо учитывать, нам также необходимо учитывать, в каких случаях используется детализация.
Поэтому :
Разбейте элементы дизайна (операции, интерфейсы, классы и агрегаты) на связанные единицы, принимая во внимание ваши интуитивные предположения о любых важных подразделениях в предметной области. Наблюдайте за закономерностями, которые изменяются и обеспечивают стабильность в ходе непрерывного процесса рефакторинга, и ищите лежащий в основе КОНЦЕПТУАЛЬНЫЙ КОНТУР, который может объяснить эти меняющиеся закономерности. Сопоставьте модель с теми непротиворечивыми аспектами предметной области, которые делают предметную область полезной совокупностью знаний.
5. АВТОНОМНЫЙ КЛАСС
Даже внутри модуля дизайн становится все труднее понять по мере добавления зависимостей. Это обременяло
наше мышление, тем самым ограничивая сложность дизайна, с которой могли справиться разработчики. Неявные понятия добавляют
больше нагрузки, чем явные ссылки.
Низкая связанность является важным элементом объектного дизайна. Держите сцепление как можно ниже. Извлеките все другие нерелевантные понятия из объекта
. Таким образом, класс становится полностью независимым, что позволяет нам изучать и понимать его индивидуально. Каждый такой независимый класс
значительно снижает нагрузку на понимание модуля.
Попробуйте выделить самые сложные вычисления в АВТОНОМНЫЙ КЛАСС (независимый класс).Один из способов добиться этого -
Смоделируйте ОБЪЕКТ ЗНАЧЕНИЯ из класса, который имеет множество зависимостей.
Низкая связанность — это самый простой способ уменьшить концептуальную перегрузку. Независимые классы — это предел низкой связанности.
6. ЗАВЕРШЕНИЕ РАБОТЫ
При необходимости определите операцию так, чтобы тип ее возвращаемого значения совпадал с типом ее аргументов. Если в вычислении будет использоваться состояние средства реализации, то средство реализации фактически является параметром операции, поэтому параметры и возвращаемое значение должны иметь тот же тип, что и средство реализации. Такая операция является операцией закрытия коллекции экземпляров этого типа. Операция замыкания обеспечивает высокоуровневый интерфейс без каких-либо зависимостей от других концепций.
Этот шаблон чаще используется для операций VALUE OBJECT.
7. Декларативный дизайн
Обычно относится к методу программирования — написанию программы или части программы в виде исполняемой спецификации (спецификации). При использовании декларативного дизайна программное обеспечение фактически управляется некоторыми очень точными описаниями свойств. Это концепция дизайна и режим работы, и через него передается философия «оставить удобство другим, а проблемы себе».
Часть IV Стратегический дизайн
1. BOUNDEDCONTEXT
Для любого крупного проекта существует несколько моделей. А когда код, основанный на разных моделях, комбинируется, программное обеспечение становится глючным, ненадежным и трудным для понимания. Общение между членами команды становится хаотичным. Люди часто путаются, в каком контексте не следует использовать модель.
поэтому:
Явно определите контекст, в котором применяется модель. Установите границы модели с точки зрения организации команды, использования различных частей программной системы и физического представления (код, схема базы данных и т. д.). Строго поддерживайте согласованность модели в этих границах, не отвлекаясь и не сбиваясь с толку проблемами за пределами границ.
2. НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ
НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ относится к достаточно частому объединению всей работы в контексте и поддержанию их согласованности, чтобы при разделении модели можно было быстро обнаружить и исправить проблемы. Как и другие методы предметно-ориентированного проектирования, НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ работает на двух уровнях: (1) интеграция концепций модели и (2) интеграция реализаций.
Поэтому :
Установите процесс для частого объединения всего кода и других артефактов реализации вместе и используйте автоматическое тестирование, чтобы быстро определить расщепление модели. Строго придерживайтесь использования ВЕЗДЕСУЩЕГО ЯЗЫКА, чтобы, когда разные концепции развиваются в умах разных людей, каждый мог прийти к консенсусу по модели.
3.КОНТЕКСТНАЯ КАРТА
Наличие только одного BOUNDED CONTEXT не обеспечивает глобального представления. Контекст других моделей может оставаться неясным и меняться.
Люди в других командах не очень хорошо осведомлены о границах КОНТЕКСТА, и они неосознанно будут вносить изменения, которые стирают границы или усложняют взаимосвязь. Когда разные контексты должны быть связаны друг с другом, они могут перекрывать друг друга.
Поэтому :
Определите каждую модель, которая играет роль в проекте, и определите ее ОГРАНИЧЕННЫЙ КОНТЕКСТ. Сюда входят неявные модели необъектно-ориентированных подсистем. Назовите каждый ОГРАНИЧЕННЫЙ КОНТЕКСТ и добавьте имя к ВЕЗДЕСУЩЕСТВУЮЩЕМУ ЯЗЫКУ.
Опишите точки соприкосновения между моделями, определите любые преобразования, необходимые для общения, и выделите любой общий контент. Сначала опишите текущую ситуацию. Внесите изменения позже. **
Как сказал президент Рейган во время переговоров о сокращении ядерных вооружений: «Доверяй, но подтверждай»**. Это предложение затрагивает суть двусторонних отношений — еще одна метафора для соединения контекстов.
4. Режим: ОБЩЕЕЯДРО
Выберите подмножество модели предметной области, которое обе команды согласны использовать. Конечно, в дополнение к этому подмножеству модели также включается подмножество кода, относящегося к части модели, или подмножество структуры базы данных. Этот раздел явного общего контента имеет особый статус и не должен изменяться одной командой без консультации с другой. Функциональные системы необходимо часто интегрировать, но частота интеграции должна быть ниже частоты НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ в команде
. По мере этих интеграций обе команды проводят тесты.
5. ГРУППА РАЗРАБОТЧИКОВ ЗАКАЗЧИКА/ПОСТАВЩИКА
Командировочная команда зависит от вышестоящей команды, но вышестоящая команда не несет ответственности за поставку продукта нижестоящей команде. Требуется много дополнительной энергии, чтобы понять, что использовать, чтобы повлиять на команду соперника, будь то человеческая природа, цейтнот или что-то в этом роде. Поэтому формализация отношений между командами облегчает работу всем. Таким образом, процесс разработки может быть организован таким образом, чтобы сбалансированно удовлетворять потребности обеих групп пользователей и планировать работу в соответствии с функциями, необходимыми на последующих этапах.
Поэтому :
Между двумя командами устанавливаются четкие отношения клиент/поставщик. На совещаниях по планированию нижестоящая команда является заказчиком вышестоящей команды. Обсудите и составьте бюджет для задач, которые необходимо выполнить, исходя из потребностей нижестоящей команды, чтобы все знали об обязательствах и прогрессе обеих сторон.
Обе команды работают вместе над разработкой автоматических приемочных тестов, которые проверяют ожидаемые интерфейсы. Добавьте эти тесты в набор тестов вышестоящей команды, чтобы они выполнялись в рамках их непрерывной интеграции. Эти тесты позволяют вышестоящей команде вносить изменения, не беспокоясь о побочных эффектах для нижестоящей команды.
6. КОНФОРМИСТ
Когда две команды разработчиков имеют отношения вышестоящего/нижестоящего, если у вышестоящей команды нет стимула удовлетворять потребности нижестоящей команды, то нижестоящая команда ничего не может сделать. Разработчики апстрима могут давать обещания из альтруизма, но могут и не выполнять их. Даунстрим-команды с благими намерениями поверят этим обещаниям, строя планы на 361, основываясь на функциях, которые никогда не воплотятся в жизнь. Нисходящие проекты можно отложить только до тех пор, пока команда, наконец, не научится использовать существующие условия, чтобы постоять за себя. Последующие команды не получат интерфейс, адаптированный к их потребностям.
Если качество апстрим-дизайна неплохое, а стиль совместимый, то отдельную модель лучше не разрабатывать. В этом случае можно использовать режим CONFORMIST (ведомый).
Поэтому :
Сложность преобразования между ОГРАНИЧЕННЫМИ КОНТЕКСТАМИ может быть устранена путем строгого следования модели вышестоящей команды. Хотя это ограничивает стиль нижестоящего дизайнера и может не привести к идеальной модели приложения, выбор шаблона CONFORMITY может значительно упростить интеграцию. Кроме того, это позволяет коллективу поставщика использовать ПОВСЕДНЕВНЫЙ ЯЗЫК. Продавцы находятся у руля, поэтому лучше упростить общение. Они делятся с вами информацией с альтруистической точки зрения.
7. АНТИКОРРУПЦИОННЫЙ СЛОЙ
Создайте уровень изоляции, чтобы предоставлять функциональные возможности клиентам на основе их собственной модели предметной области. Этот уровень общается с другой системой через свой существующий интерфейс с небольшими модификациями этой системы или без таковых. Внутри этот уровень выполняет необходимые двунаправленные преобразования между двумя моделями.
8. ОТДЕЛЬНО
Интеграция всегда стоит дорого, а выгода иногда невелика.
поэтому:
Объявление ОГРАНИЧЕННОГО КОНТЕКСТА, не связанного с другими контекстами, позволяет разработчикам находить простые специализированные решения в рамках этой небольшой области .
9. УСЛУГА ОТКРЫТОГО ХОЗЯИНА
Когда подсистема должна быть интегрирована с большим количеством других систем, настройка уровня перевода для каждой интеграции может замедлить аналитический паралич команды, который относится к скорости, с которой проект увязает перед лицом больших усилий по анализу. Будет все больше и больше вещей, которые нужно поддерживать, и все больше и больше вещей, о которых нужно беспокоиться при внесении изменений.
Поэтому :
Определите протокол для обработки вашей подсистемы как набора УСЛУГ для доступа других систем. Откройте протокол, чтобы любой, кому необходимо интегрироваться с вашей подсистемой, мог его использовать. Этот протокол совершенствуется и расширяется по мере возникновения новых потребностей в интеграции, за исключением особых потребностей отдельных групп. Решение этой конкретной потребности состоит в дополнении протокола одноразовыми преобразователями, чтобы сохранить общий протокол простым и связным.
10. ПУБЛИКУЕМЫЙ ЯЗЫК
немного