Please enable JavaScript.

Coggle requires JavaScript to display documents.

Предметно-Ориентированное Проектирование (Domain-Driven Design) - Coggle…

- - - - Части эффективного моделирования
        
        Связь между моделью и ей реализацией
        
        Общий язык, основанный на модели
        
        Разработка информоёмкой модели
        
        Объекты имеют заданные правила и ограничения. Модель отражает методику поставленной задачи
        
        Дистилляция модели
        
        Добавление новых важный понятий
        
        Удаление второстепенный вещей
        
        Выделение второстепенный вещей как основных
        
        Эксперименты и мозговые штурмы
        
        Проверка различных сценариев работы приложения на получившейся модели
    - - Извлечение скрытого понятия. Например выделение части функции объекта в отдельный объект Стратегия, содержащий специфический алгоритм
  - - - Необходимо привести жаргон программистов, жаргон аналитиков и других специалистов к единому языку для описания предметной области.
        
        Нельзя выделить ни один из даиалектов в качестве ЕДИНОГО ЯЗЫКА (UBIQUITOUS LANGUAGE)
      - Наличие единого языка позволяет связывать описание модели, её реализацию в коде, описание use case'ов
      - Модель - основа для языка. Необходимо пользователь этим язык в первую очередь в разговоре
      - Экспериментируйте с альтернативными выражениями и терминами отражающие альтернативные модели
        
        Переименуйте классы, обновляйте модели, рефакторите код, если это необходимо для соответствия новым терминам
        
        Ликвидируйте путаницу в терминах путём устных обсуждений
      - Изменения в ЕДИНОМ ЯЗЫКЕ - это изменения в модели
      - Необходимо отслеживать любую неоднозначность и непоследовательность в терминологии, так как это ведёт к более запутанной модели из-за чего страдает архитектура приложения
    - - Один из лучших способов улучшить модель - обкатывать ее на языке, описывая конструкции вслух. Шероховатости будут услышаны сразу же
      - Говоря о системе, "играйте" с моделью, описывая сценарии вслух. Ищите более простые способы выразить мысль и привносите эти изменения в модель и в код
    - - Если не программисты не понимают модель - значит с моделью что-то не так.
      - Обсуждение единой модели на ЕДИНОМ ЯЗЫКЕ позволит сразу выявить её недостати с разных углов зрения
      - Специальный жаргор/термины разных групп специалистов (программистов/аналитиков) могут только дополнять единый язык
    - - Письменная проектная документация
        
        Документация должна дополнять код и устные обсуждения
        
        НЕ надо возлагать на документацию те задачи, с которыми хорошо справляется сам код
        
        В документации необходимо отразить ключевые элементы, помочь прояснить смысл архитектуры
        
        Документация должна активно работать и не отставать от процесса
        
        Схемы, нарисованные от руки создают ощущение временности и неформальности. Это позволяет во-первых быстрее их изображать, а во вторын не бояться их изменять
        
        Если термины, описанные в документе, перестали употребляться в дискуссиях и разговорах - это повод задуматься, что документ устарел или вообще не используется, тогда его можно либо обновить, либо отправить в архив, ибо в активном состоянии в текущем устаревшем виде он только вредит.
      - Выполняемый код решает всё
        
        Необходимо приложить усилия, что бы код не только делал то, что нужно, но и сообщал об этом в письменном виде путём использования явных названий методов, переменных и проч.
        
        Использование практик декларативного программирования
      - Не надо пытаться всё вместить в диаграммы и UML-схемы. Естественный язык также может отлично справляться с задачей дополнения и описания модели
      - Модель - это НЕ схема
      - Все существенные подробности архитектуры заключаются в исходном коде
    - - Вовсе НЕ должны быть модельными, скорее даже наоборот было бы хорошо, если бы пояснительная модель была выполнена иначе, тем самым более ясно показывая, что это не основная модель. Необходимо чётко отличать пояснительные и основную модель
      - Помогает специалистам из разных команд лучше понять предметную область с разных углов зрения
  - - - Разрабатывать отдельно аналитическую модель и программную архитектуру - не самая лучшая идея
      - Программа должна отражать модель самым буквальным образом
    - - Явно использовать ООП средства Языка Программирования, реализация классов (абстрактных и конкретных) для сущностей модели
    - - В идеале дать пользователю понять, какая модель и архитектура применена в приложении, как приложение работает изнутри в целом, дать пользователю понять внутренние механизмы реализации программы, чтобы он лучше понял потенциал программы и её возможности
    - - Сотрудник, пишуший код, должен иметь возможность изменять модель
      - Если в результате рефакторинга программы не меняется модель - это плохой рефакторинг.
      - Каждый программист является моделировщиком
      - Даже руководителей, которые влияют на модель, необходимо привлекать к пониманию программного кода
- - - - Необходимо разбить приложение на слои. Внутри каждого слоя должна быть чёткая структура, которая может вызывать код либо со своего уровня, либо с нижестоящих уровней. См. Onion Architecture
      - Код предметной области необходимо сосредоточить в одном слое и изолировать его от интерфейса пользователя
      - Концептуальные уровни
        
        Интерфейс пользователя
        
        Вывод информации пользователю и интерпретация его команд. Например Spring Controller
        
        Операционный уровень
        
        Распределяет поступившие команды, НЕ должен содержать бизнес правила. Service
        
        Уровень предметной области
        
        Содержит бизнес правила, тут сосредоточена модель и предметная область. Главный алгоритмический уровень программы
        
        Инфраструктурный уровень
        
        Обеспечивает техническую поддержку, по факту уровень фреймворка вроде Spring, который отвечает за работу с БД, поддержку транзакционности, сетевыме протоколы, обмен разных сообщений и прочее подобное
      - Связь между уровнями
        
        Уровни не должны быть связаны жёстко и зависимости направлены только в одну сторону.
        
        Для связи нижнего уровня с верхним используются callback'и или паттерн НАБЛЮДАТЕЛЬ или модель событий
      - Архитектурные среды (фреймворки)
        
        Позволяют помогать решать многие сложные технические задач, предоставив разработчику возможность сосредоточиться на предметной области и модели.
        
        В то же время фреймворки могут сковвывать движения, поэтому надо ими пользоваться с осторожностью, постараться явно не добавлять в код предметной области.
    - - Модель находится на уровне предметной области. Бизнес-логика базируется на модели и находится там-же и должна быть отделена от прочих частей приложения, должна быть независимой
    - - При разработке небольшого и несложного приложения, особенно когда команда недостаточно квалифицирована - нет смысла заморачиваться с DDD
      - В простыл случаях можно помещать безнес-логику прямо на уровень интерфейса пользователя
        
        плюсы
        
        быстрая разработка
        
        можно применять при недостаточной квалификации
        
        чёткое разделение логики и интерфейсов. Это позволяет легко вносить новые элементы с новой бизнес-логикой в интерфейс (простое расширение системы за счёт новых модулей)
        
        минусы
        
        Сложно осуществляется интеграция нескольких приложений
        
        Дублирование бизнес-правил для похожих UI-элементов
        
        Ограниченные возможности для рефакторинга
        
        Экспоненциально возрастающая сложность разработки при серьёзном усложнении бизнес-правил
  - - - 3 способа сделать ассоциации удобными
        
        Добавить квалификаторы => снизить кратность
        
        Например добавить к связи Страна : 1 - N : Президент квалификатор Период, так что получаем связь Период - Президент как 1 : 1
        
        Устранить несущественные ассоциации
        
        Свести отношения к однонаправленным
      - это связи/отношениями между элементами модели-программы
    - - Такие объекты, определение которых только через набор атрибутов не является главным.
      - Представляют собой индивидуальное существование в пределах всего жизненного цикла (при разных состояниях)
      - По сути уникальный идентификатор - то, что определяет уникальность сущности
    - - Не имеют уникальности, идентификатора
      - если два VALUE OBJECT'a совпадают по атрибутам - значит они неразличимы
      - Иногда их можно "встраивать в сущности" при сохранении в БД
      - В идеале объект должен быть неизменяемый
      - необходимо делать объект максимально простым
      - Могут содержать ссылки на СУЩНОСТИ
    - - Это операция, которую не удаётся поместить в СУЩНОСТЬ
      - не должен иметь состояния
      - Службы могут быть на разных уровнях, на инфраструктурном, на прикладном, на уровне модели.
    - - модуль - полноценная структура модели
      - не надо боястся рефакторить модули
      - модули содержат связанные между собой понятия таким образом, что импортируя все классы из модуля разом не возникает дискомфорта
      - давать модулям такие имена, которые войдут в ЕДИНЫЙ ЯЗЫК
      - Ловушки инфраструктуры
        
        Некоторые фреймворки могут накладывать определённые правила формирования мудулей и пакетов - стоит относиться к этому с осторожностью
        
        Не стоит разбивать классы, тесно связанные между собой, в различные пакеты. Нельзя разделять до бесконечности и стоит всё же объединять классы в осмысленные пакеты
        
        Если нет необходимости разделять код между серверами - храните ведь код, реализующий концептуальный объект в одном МОДУЛЕ, а то и классе!
        
        Используйте разбиение на пакеты чтобы отделить уровень предметной области от остального кода. На уровне предметной области у разработчика должна быть максимальная свобода в выборе способа разделения на пакеты
    - - Причины доминирования объектной парадигмы
        
        На данный момент именно ООП - доминирует, остальные под неё подстраиваются. Именно ООП позволяет максимально удобно кодить при ПРОЕКТИРОВАНИИ ПО МОДЕЛИ (за исключением специфических доменный областей вроде математических формул)
      - Не-объекты в объектном мире
        
        Иногда в хорошей ООП модельке встречаются несколько не-объектных вещей, выраженных в другой парадигме. Если таких объектов немного, то вполне можно смириться.
        
        Если большинство объектов легче описать в другой. не объектной парадигме, то есть смысл подумать от объектной модели в целом
        
        Если объектов приблизительно поровну, то можно прибегнуть к смешиванию парадигм, в том числе используя rule engine или workflow engine используя самые подходящие средства для моделирования того или иного момента.
      - Проектирование по модели в условиях смешения парадигм (на примере использования rule engine)
        
        Работая с бизнес правилами важно не забывать думать об них в контексте ЕДИНОГО ЯЗЫКА
        
        Список правил добавления ООП в необъектную систему:
        
        Не противоспоставлять парадигме реализации. Необходимо найти концепции, которые соответствуют парадигме (???)
        
        Полагаться на ЕДИНЫЙ ЯЗЫК
        
        Не задикливаться на UML
        
        Всё подвергать сомнению. Может быть можно отказаться от rule engine и заиспользовать ООП на полную мощность
  - - - Агрегат - совокупность взаимосвязанных объектов, которые мы воспринимаем как единое целое
      - Содержит одну корневую СУЩНОСТЬ и имеет границу
      - Может содержать как СУЩНОСТИ, так и ОБЪЕКТЫ-ЗНАЧЕНИЯ
      - Все НЕ корневые объекты уникальны только в пределах агрегата
      - Набор правил для любой транзакции
        
        корневая СУЩНОСТЬ имеет глобальную идентичность и отвечает за выполнение инвариантов
        
        не корневые СУЩНОСТИ имеют локальную идентичность, уникальны только в пределах агрегата
        
        Нигде за пределами агрегата не должны надолго сохраняться ссылки на внутренние объекты, но их можно передавать временно и лучше - ПО ЗНАЧЕНИЮ
        
        Внутренние объекты АГРЕГАТА могут хранить ссылки на другие АГРЕГАТЫ
        
        Все обращения к внутренним объектам должны происходить только через корневую СУЩНОСТЬ
    - - Если создание объекта или агрегата - сложная операция, которая требует соблюдения многих инвариантов - имеет смысл вынести этот код в ФАБРИКУ
      - Каждый метод создания объекта должен быть один и не делим; должно гарантироваться соблюдение всех инвариантов
      - Абстрагировать фабрику лучше по желаемому типу, а не по классу, используя шаблоны (Абстрактная фабрика, фабричный метод, Построитель)
      - Фабрику лучше помещать рядом с создаваемым объектом, тем более что фабрика знает о внутреннем устройстве этого объекта, а значит довольно тесно связана
      - Когда использовать простой конструктор
        
        Класс является типом, т.е. существует всего одна реализация и возможно даже не существует ни одного интерфейса
        
        Клиенту нужно знать реализацию объекта
        
        Все атрибуты уже доступны, не создаются дополнительные объекты
        
        Создание объекта относительно простое
      - Логику инвариантов можно дополнительно реализовать только в фабрике, особенно если это создание ОБЪЕКТОВ ЗНАЧЕНИЙ, когда все данные инициализируются только в процессе создания
      - Восстановление хранимых объектов
        
        Т.е. например загрузка из БД или парсинг из XML/JSON файла
        
        Основные отличия фабрики по восстановлению от обычно фабрики по созданию
        
        Фабрика по восстановлению не присваивает новый идентификатор
        
        Фабрика восстановления по другому обрабатывает нарушение инвариантов, требуется более гибкий подход.
    - - Инкапсулирует в себе всю логику работы с БД (в общем смысле, это может быть и простая файловая система)
      - Может содержать как методы, возвращающие явные значения по определённым критериям, так и "абстрактные" методы, возвращающие значение на основании спецификации
      - При восстановлении объектов при загрузке из БД могут использовать специальные ФАБРИКИ
      - Оставьте контроль за транзакциями клиенту!
      - Советы по проектированию объектов для реляционной БД
        
        нельзя позволять модели данных и модели объектов расходиться слишком далеко. Для этого скорее всего придётся идти на компромисы.
        
        иногда имеет смысл не заморачиваться и "вставлять" ОБЪЕКТЫ-ЗНАЧЕНИЯ прямо в одну учейку в БД, т.е. денормализовать таблицу, не плодить лишних таблиц
        
        Бывают ситуации, когда схема в БД и модель расходятся кардинально. В таком случае лучше оставить попытки свести одно с другим и сознадельно держать модель и схему отличными, при этом можно разрабатывать и поддерживать схему в идеальном виде и модель развивать независимо, не пытаясь скрестить бульдога с носорогом.
- - - - Явные условия-ограничения. Имеет смысл выносить проверки условаий в отдельные методы или иным способов выделить их в рамках кода предметной области
      - Процессы как объекты предметной области. Выделание процессов в виде СЛУЖБ или СТРАТЕГИЙ
      - Спецификация. Что-то вроде гибрида предиката и доменного объекта. SpecImpl.isSatisfiedBy(objToCheck)
        
        Проверка пригодности. Проверить, удовлетворяет ли объект заданным условиям в спецификации
        
        Отбор по запросу. Фильтрация коллекция объектов по указанной спецификации, либо запрос в БД объектов, удовлетворяющих спецификации
        
        Создание по заказу (я так понял, что речь скорее про заполнение объектов-контейнеров). Использование спецификации при создании объекта, убирая из кода "генератора" избыточные проверки + позволяет с помощью спецификации провалидировать получившийся результат
  - - - Можно попробовать использова специальные DSL языки для описания элементов архитектуры
      - При разработке сложных СПЕЦИФИКЦИЙ тоже можно использовать декларативный стиль. Хороший пример - Spring Expression Language (SpEL)
    - - Выделение подобластей - не обязательно перерабатывать всю архитектуру разом. Достаточно сосредоточиться на отдельный частях и перерабатывать их постепенно.
      - Использование сложившихся формальных систем, например математических терминов и определений. ФП этим очень активно пользуется.
      - Разделение команд на функции без побочных эффектов
      - Использование цепочек-вызовов, которые возвращает Immutable VALUE-OBJECT
  - - - Стратегия. Например стратегия поиска маршрута в навигаторе: может быть стратегия самого быстрого маршрута, может быть стратегия самого короткого маршрута или какая-либо смешанная стратегия.
      - Композит. В приложении по составлению маршрута доставки карты каждый маршрут может быть составлен из под-маршрутов. Главное, чтобы у них был одинаковый интерфейс.
- - - - В большом проекте нет необходимость пытаться строить универсальную модель на всё приложение целиком. Достаточно поистроить модель для ограниченной области, в рамках ограниченного контекста. Но необходимо ясно определить границу этой модели.
      - Ограниченный контекст это не модуль.В рамках одного контекста может быть несколько модулей
      - Например в приложении по доставке грузов одна модель может случить для обработки заказов и другая модель - для поиска маршрута. Каждая модель будет развиваться и находиться в рамках своего ограниченного контекста
      - Распознавание дефектов
        
        Дублирование. Когда в модели существуют две реализации одного и того же понятия. В случае обнаружения необходимо избавиться от одной из реализаций
        
        Ложные родственники - это когда пользуются одним и тем же объектом модели, хотя по факту используют его в совершенно разных целях и правильно разделить таких "родственников" на два разных объекта
    - - Когда в одном контексте работает несколько групп людей то модель имеет тенденцию к фрагментации.
      - Необходимо:
        1) иметь автоматизированную регулярную систему сборку проекта
        2) Автоматизированные тесты
        3) Регулярные обсуждения
        4) Упорно практиковаться в ЕДИНОМ ЯЗЫКЕ
    - - Необходимо дать каждому ограниченному контексту уникальное имя из ЕДИНОГО ЯЗЫКА, а так же определить точки соприкосновения ограниченных контекстов
      - Связи ОГРАНИЧЕННЫХ КОНТЕКСТОВ можно неформально изобразить на схеме
      - Схема взаимодействия определяется Translator'ом/Converter'ом из модели/языка одного ОГРАНИЧЕННОГО КОНТЕКСТА в другой.
      - Необходимо иметь автоматизированные тесты (интеграционные?) точек соприкосновения контекстов
      - Каждый разработчик должен знать, в каком ограниченном контексте находит тот или иной случайно выбранный элемент кода и без знать, где проходят границы
        этого ограниченного контекста
    - - Самый простой случай унификации - "цасть - целое", когда независимые модели объединяются в качестве частей одного целого
        Сложнее, когда часть моделей описывают одно и тоже, но под разными углами, тогда в большинстве случаев разумнее использовать наименьшую общую часть в качестве абстракции
    - - Преобразование границ
        
        Преимущества больших контекстов
        
        Одна унифицированная модель и более тесная связь различных пользовательских операций
        
        Легче понять одну связную модель
        
        Отсутствие сложной (а порой и невозможной) трансляции между разными моделями
        
        Общий язык
        
        Преимущества малых контекстов
        
        снижаются издержки коммуникации между разработчиками
        
        Отсутствие необходимостив большой и сложной универсальной модели для создания которой нужны квалифицированные кадры
        
        Небольшие модели можно сделать более точными + для них легче организовать НЕПРЕРЫВНУЮ ИНТЕГРАЦИЮ
      - Выбор отношений с внешними системами
        
        Прежде всего необходимо рассмотреть возможность ОТДЕЛЬНОГО СУЩЕСТВОВАНИЯ.
        Остальные варианты: КОНФОРМИСТ или ПРЕДОХРАНИТЕЛЬНЫЙ УРОВЕНЬ:
        Модель старой системы может оказаться удобной в небольших периферийных расширениях, если это так - то КОНФОРМИСТ - то, что надо.
        Если же изменения более глобальные - реализовать свой собственный ОГРАНИЧЕННЫЙ КОНТЕКСТ с трансляционными и возможно ПРЕДОХРАНИТЕЛЬНЫМ УРОВНЕМ
      - Проектируемая система
        
        Один ОГРАНИЧЕННЫЙ КОНТЕКСТ - хороший выбор для группы из менее 10 человек.
        При бОльшем количестве человек нужно подумать либо об ОБЩЕМ ЯДРЕ, либо о модели ЗАКАЗЧИК-ПОСТАВЩИК.
        При невозможности совместной разрабтке выбирать ОТДЕЛЬНОЕ СУЩЕСТВОВАНИЕ (SEPARATE WAYS), либо ПРЕДОХРАНИТЕЛЬНЫЙ УРОВЕНЬ
      - учёт особых случаев отдельными моделями
        
        можно выделить независимый КОНТЕКСТ для ОТДЕЛЬНОГО СУЩЕСТВОВАНИЯ. Если же у двух диалектов языка много общего, имеет смысл выделить ОБЩЕЕ ЯДРО.
        В любом случае при выделении отдельной модели необходимо не забывать о том, что существует ещё и другая основная модель. Это может привести к тому, что в будущем, потенциально, после углубления модели получится построить общую универсальную модель, которая будет отлично подходить всем.
      - Установка
        
        Самый просто вариант разворачивания приложения - когда оно в виде НЕЗАВИСИМОГО СУЩЕСТВОВАНИЯ. В остальных случае необходимо будет учитывать кучу нюансов с версионированием и обновлением данных, особенно сложно в случае ОБЩЕГО ЯДРА
      - Компромиссы
        
        существует целый ряд стратегий унификации, но всегда необходимо искать компромисс, золотую середину
      - Если проект уже в работе
        
        в самом начале необходимо построить КАРТУ ОГРАНИЧЕННЫХ КОНТЕКСТОВ в текущем состоянии и уже только после этого приступать к преобразованиям.
    - - Слияние контекстов: от отдельного существования к общему ядру.
        
        Оценить начальную модель и убедиться, что оба контекста едины по смыслу
        
        Подготовить процесс, определить порядок работы, подготовить тесты до начала реального слияния
        
        для начала выбрать некоторую под-область, которая дублируется в обоих контекста, которая не критично важна и выполнить работу на ней, обкатывая процессы.
        
        сформировать группу разработчиков из обеих команд для разрабтки общей модели подобласти.
        
        Каждая группа начинает реализию модели. При возникновении проблем с моделью см. П.4.
        
        Каждая команда начинает интеграцию с ОБЩИМ ЯДРОМ.
        
        Убрать уровень трансляции, который больше не нужен.
        
        Если одна из моделей однозначно лучше другой - не лучше ли перейти сразу не неё вместо интеграции???
      - Слияние контекстов: от общего ядра к непрерывной интеграции
        
        Убедитесь, что все процессы, необходимые для НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ поручены обоим командам, сделать эти процессы одинаковыми в обоих группах.
        
        Начните циркуляцию разработчиков между группами.
        
        Объявите дистилляцию(см. главу 15) каждой модели.
        
        Начать переливать СМЫСЛОВОЕ ЯДРО (CORE DOMAIN) в ОБЩЕЕ ЯДРО(SHARED KERNEL). Взявшись за смысловое ядро нужно попытаться сделать этот процесс максимально быстро.
        
        По мере роста ОБЩЕГО ЯДРА необходимо увеличивать частоту интеграции в итоге до НЕПРЕРЫВНОЙ
      - Вытеснение устаревшей системы
        
        Определите специфические ф-ии старой системы, которые можно перенести в новую за одну итерацию.
        
        определите модификации, которые потребуются на ПРЕДОХРАНИТЕЛЬНОМ УРОВНЕ
        
        Реализовать
        
        Установить
        
        Удалить ненужные части из ПРЕДОХРАНИТЕЛЬНОГО УРОВНЯ
        
        Попробовать вырезать неиспользуемые модули из старой системы, если это возможно
        
        Перейти на п.1 до полного удаления старой системы
      - От открытого протокола к общедоступному языку
        
        Если в отрасли есть стандартный язык для общема данными - по возможности использовать его
        
        Если такого стандартного языка нет, то выделить СМЫСЛОВОЕ ЯДРО(CORE DOMAIN), которое будет служить сервером открытого протокола (см. главу 15)
        
        Используйте СМЫСЛОВОЕ ЯДРО как снову языка коммуникации, наподобие XML
        
        Опубликуйте новый язык
        
        Опубликуйте архитекутуру системы, если это важно
        
        Постройти трансляционный уровень для каждой подключаемой к нам системы.
        
        Переключиться на новую систему (???)
    - - Общее ядро
        
        Некоторое общее подмножество кода и модели выделяется в виде ЯДРА.
        Конмандам запрещено вносить туда изменения без подтверждения других команда, которые работают с этим ядром.
        Обоим командам необходимо объединить свои тестовые наборы, чтобы случайно не поломать код друг друга.
        Ядро представляект собой SUB-DOMAIN
      - Группу "Заказчик-поставшик"
        
        Когда "нижняя" (использующая API/Код "вернхней") команды и верхняя команда так или иначе находятся под одним управленцем, который заинтересован в успехе "нижней" команды, то такая команда оказывается в положении "ЗАКАЗЧИК" для верхней команды участвует как полноценный заказчик изменений вместе с остальными внешними заказчиками.
        Необходимо разработать специадбгые приёмочные тесты для того, чтобы "верхняя"(ПОСТАВЩИК) реализовала ожидаемые от неё интерфейсы корректно
      - Конформист
        
        Если команды находятся в отношении "верхних". но нет возможности построить взаимоотношения "заказчик-поставщик", то у "нижней" команды могут возникнуть проблемы.
        Если модель "нижней" команды относительно невелика, то можно сгладить сложность трансляции моделей тем, что "нижняя" команда принимает модель "верхней" команды
      - Предохранительный уровень (ANTICORRUPTION LAYER)
        
        Когда модели взаимодействующих систем достаточно больши и самостоятельны, имеет смысл добавить дополнительный "изолирующий слой" между ними
        Этот уровень будет общаться с моделими обоих систем на их API и внутри себя производиться конвертацию понятий одной модели в другую.
        
        Проектирование интерфейса предохранительного уровня
        Интерфейс предохранительного уровня обычно реализуется в виде набора СЛУЖБ, но иногда можно выступать и в виде СУЩНОСТИ, которая представляет внешнюю систему в терминах нашей модели
        
        Реализация предохранительного уровня
        
        Транслятор ^ | Наша подсистема -> [Служба -> Адаптер -> Фасал] -> Внешняя система
      - Службы с открытым протоколом
        
        Если предполагается, что ваша система будет использоваться многими внешними службами, то есть смысл разработать и предоставить для них публичный API
      - Отдельное существование
        
        Иниеграция не всегда необходима
        
        По возможности надо пытаться отказаться от интеграции. можно например выносить некоторые необходимые вещи в виде отдельных скриптов и приложений.
        
        Иногда интеграцию можно оставить только на уровне middleware или даже инфраструктурного уровня, а бизнес-модели при этом будут полностью независимыми
      - Общедоступный язык
        
        Пользуйтесь всеми известными общедоступными "языками". Например для передачи электронных документов между разными ЭДО используется специальный формат МЭДО.
  - - - Необходимо "упарить" модель до минимума. Найдите СМЫСЛОВОЕ ЯДРО, которое можно легко отличить от вспомогательных частей модели.
        Направьте на разработку СМЫСЛОВОГО ЯДРА лучшие кадры.
    - - от простого к сложному: ВВЕДЕНИЕ В ПРЕДМЕТНУЮ ОБЛАСТЬ -> СХЕМАТИЧЕСКОЕ ЯДРО -> НЕСПЕЦИАЛИЗИРОВАННЫЕ ПОДЪОБЛАСТИ -> СВЯЗНЫЕ МЕХАНИЗМЫ -> ВЫДЕЛЕННОЕ ЯДРО -> АБСТРАКТНОЕ ЯДРО
    - - Для начала можно отделить менее специализированные аспекты модели. Определите, какие подобласти не являются часть основной модели приложения, того, что делает модель приложения уникальной.
        Такие подобласти необходимо вынести в отедльные модули и полностью избавить их от знаний об основной модели.
      - Для неспециализированных подобластей в виде отдельных модулей необходимо установить пониженный приоритет разработки по сравниню со СМЫСЛОВЫМ ЯДРОМ (Core domain)
      - Доступные варианты реализации неспециализированных подобластей
        
        Вариант 1. Готовое решение. Иногда можно купить готвоое решение или заиспользовать открытый общедоступный код.
        
        Преимущества
        
        Меньше кода писать самим
        
        Вопросы сопровождения и доработки выносятся за пределы проекта
        
        Код написан лучше, лучше оттестирован
        
        Недостатки
        
        Придётся изучать и оценивать чужой код перед использованием
        
        Нельзя полностью рассчитывать на его правильность и надёжность
        
        Код может быть перегружен лишними элементами, которые никогда не будут использоваться
        
        Сложность интеграции с другой моделью
        
        Могут появиться дополнительные зависимости от платформы, компилятора, и т.п.
        
        Вариант 2. Общедоступная архитектура или модель
        
        Преимущества
        
        Более проработанная модель, чем "доморощенная"
        
        наличие качественной документации
        
        Недостатки
        
        Может оказаться перегруженной лишними элементами
        
        Вариант 3. Вынос решения на аутсорсинг
        
        Преимущества
        
        Освобождает ключевых сотрудников от работы над СМЫСЛОВЫМ ЯДРОМ
        
        Позволяет вести дополнительную разработку, не рассеивая знанеия о СМЫСЛОВОМ ЯДРЕ
        
        Вынуждает к интерфейсно-ориентированному проектированию
        
        Недостатки
        
        Всё-такие требуют затрат времкни основных разработчиков
        
        Дополнительные трудозатраты на передачу кода (но эти затраты всё равно меньше самостоятельной разработки)
        
        Качество кода может оказаться переменчивым
        
        Вариант 4. Собственная реализация.
        
        Преимущества
        
        Простота интеграции
        
        Получаете именно то, что нужно и ничего лишнего
        
        можно привлекать временных испольнителей
        
        Недостатки
        
        Затраты на сопровождение и обучение
        
        Легко недооценить время и стоимость такой разработки
      - "Неспециализированный не значит "Хорошо переносимый".
        Код неспециализированный подобластей не обязательно делать универсальным, даже наоборот, чем проче он решает только поставленную задачу - тем лучше.
    - - Фокусируется на общих характеристиках модели предметной области и на её ценности для бизнеса
      - Кратко опишите предметную область и её полезность без технических деталей!
    - - Все члены команды хотябы в общих чертах должны представлять, из чего состоит СМЫСЛОВОЕ ЯДРО (CORE DOMAIN)
      - Дистиляционный документ
        
        Это одна из форма СХЕМАТИЧЕСКОГО ЯДРА (HIGHLIGHTED CORE) - краткий документ (от 3 до 7 страниц крупным шрифтом) в котором описывается СМЫСЛОВОЕ ЯДРО и основные взаимодействия между элементами ЯДРА
      - Разметка ядра
        
        Если модель уже есть в том или ином виде (диаграмма классов, UML, JavaDoc), то необходимо отметить тем или иным образом, какой объект входит в СМЫСЛОВОЕ ЯДРО, а какой нет, не особо вдаваясь в детали.
      - Дистиляционный документ как методическое средство
        
        Дистиляционный документ служит индикаторам важности изменений в модели.
        Если изменения затрагивают дистиляционный документ - значит эти изменения должны обсуждаться со всеми членами команды.
        Если это другие изменения, то их можно делать относительно автономно
    - - Вынесите СВЯЗНЫХ МЕХАНИЗМ (COHESIVE MECHANISM) в отдельную програмную среду или библиотеку. Обозначте фунциональный возможности этот библиотеки с помощью ИФНОРМАТИВНОГО ИНТЕРФЕЙСА (INTENTION REVELING INTERFACE). При этом на вопрос "что делать" будте отвечать основная модель, а "как делать" - связный механизм
      - Пример
        
        Если есть древовидная организационная схема с департаментами, подчинёнными, начальниками и проч., то можно выделить модель, оперирующую математическими графами в виде СВЯЗНОГО МЕХАНИЗМА, а основной код освободить от технических деталией вроде обхода графа.
      - Сравнение связных механизмов и неспециализированных подобластей
        
        С первого взгляда можно подумать, что это одно и тоже - основная их задача - разгрузить СМЫСЛОВОЕ ЯДРО.
        Разница в принимаемых на себя обязанностях.
        НЕСПЕЦИАЛИЗИРОВАННАЯ ПОДОБЛАСТЬ основана на смысловой модели, взгляд разработчика на общую проблему. По сути она не отличается от взглядя на СМЫСЛОВОЕ ЯДРО, только является менее центральной и важной.
        СВЯЗНЫЙ МЕХАНИЗМ никак не представляет предметную модель, решает лишь вычислительную, техническую задачу
    - - когда все побочные и вычислительные элементы вынесены из смыслого ядра, он может стать настолько простым, что может начать функционировать как язык, который можно представить в виде DSL
    - - Необходимо отделить от ядра все вспомогательные элементыф, вынести их в отдельные модули или пакеты
      - Этапы рефакторинга
        
        Определите подобласть СМЫСЛОВОГО ЯДРА
        
        Классы, имеющие к ней отношения переносятся в новый модуль
        
        Выполняется рефакторинг кода при котором "отрезаются" данные и функционалные возможности, не имеющие прямого отношения к подобласти
        
        Выполняется рефакторинг нового получшенного МОДУЛЯ ВЫДЕЛЕННОГО ЯДРА с целью упрощения и повышения информативности.
        
        Выполнить п.1 с другой подъобластью
      - Эволюция коллективных решений
        
        Решение о переходе к ВЫДЕЛЕННОМУ ЯДРУ должно приниматься всей группой или как минимум каждый член команды должен об этом знать и иметь представление о том, в каком напралении двигается рефакторинг и как его надо осуществлять.
    - - Если количество модулей становится очень велико и между модулями происходит интенсивное взаимодействие, то это ухудшает наглядность модели.
      - Можно выделить самый общие фундаментальные понятия модели в виде абстрактеых классов, интерфейсов в отдельный модуль и использовать везде, оставив конкретные реализации в других модулях.
    - - В рефакторинге "по наболевшему" (самые преблемные участки) следует проверить, есть ли проблема в СМЫСЛОВОМ ЯДРЕ, если да, то устранить
      - Есть есть возможность начать рефакторинг откуда угодно, то тогда лучше начать с реорганизации СМЫСЛОВОГО ЯДРА, более чёткого выделения ЯДРА, очистки вспомогательных подобластей до состояния НЕСПЕЦИАЛИЗИРОВАННЫХ (GENERIC SUBDOMAINS)
    - - Помогает понять архитектуру и взаимосвязь компонентов
        
        Облегчает процесс коммуникации, так как модель становится обозримой величины
        
        Задаёт направление для рефакторинга
        
        Фокусирует внимание на основных частях приложения
        
        Помогает определиться с аутсорсингом, использованием готовых компонентов
  - - - Системы, разрабатываемые хаотически, никто не способен воспринимать как единое целое и разрабатывать и поддерживать в долгосрочной перспективе
      - Не накладывайте слишком жёстких ограничений на архитектуру и модель, такие решение необходимо принимать на основании детализированных знаний
      - В отличии от КАРТЫ КОНТЕКСТОВ (CONTEXT MAP), крупномасштабная структура - вещь не обязательная.
        Крупномасштабную структуру надо вводить только тогда, когда она делает систему понятнее, не накладывая неестественных ограничений на модель.
        Плохая структура хуже, чем вообще никакая, т.е. лучше её вообще не делать, если она плохая
    - - Если возникает образ, захватывающий воображение и подходящий под наглядное приблизительное объяснение системы - используйте его в качестве крупномасштабной структуры
      - Пример. Брандмауэр - это метафора, изначально это "огненная стена", спасающая здания от пожара на соседних зданиях. В ПО используется как программа, защищающая от угроз извне.
      - Избегайте "наивных образов", типа "платёжная система ну это типа конвейер", вместо этого в качестве образа можно использовать ЕДИНЫЙ ЯЗЫК (UBIQUITOUS LANGUAGE)
    - - Чтобы придать системе связность, распределению обязанностей полезно придать структуру.
      - Изучите коцептуальные взаимосвязи в вашей модели, различия в скорости изменений участкой модели.
        Если в модели естественным образом уже присутствует расслоение - то необходимо слои представить в виде обобщённых абстрактных групп обязанностей.
      - Выбор подходящих уровней
        
        Примеры уровней
        
        Потенциал (Potential)
        
        Что мы можем делать? Выражает текущие активы
        
        Операции (Operations)
        
        Что на самом деле происходит? Что удалось извлечь из имеющегося потенциала?
        На этом уровне мы пытаеся увидеть наши усилия и виды деятельности.
        
        Поддержка решений (Decision Support)
        
        Какие действия следуюет предпринять, какой установить регламент?
        На этом уровне выполняется анализ и принимаются решения.
        
        Регламент (Policy)
        
        Каковы установленные правила и цели?
        Правила и цели носят пассивный характер, но накладывают ограничения на другие уровни.
        
        Обязательства (Commitment)
        
        Какие мы дали обещания и кому?
        По характеру уровень похож на регламент, но и на операционный
        
        В общем случае не стоит делать более 5-и уровней. Не стоит принудительно пытаться приводить архитектуру к данным конкретным уровням, надо смотреть по своей конкретной ситуации.
    - - Позволяет "кастомизировать" модель под нужны конкретных пользователей
      - Например конфигурирование связей между сущностями прямо в БД
      - Создайте набор объектов для описания структуры и функции базовой модели, разделите на уровни - один предельно конкретный. другой конфигурируется супер-пользователем и содержит мета-информацию
    - - В некоторых случаях удобно использовать готовый фреймворк, позволяющий с помощью АБСТРАКТНЫХ ИНТЕРФЕЙСОВ интегрировать ваше расширение и уже сущетсвующее, возможно огромное, приложение
      - Среда определяет базовые интерфейсы и базовые ограничения, которым должны подчиняться наши кастомные компоненты
    - - Хорошая структура маловероятно будет известна на старте, а только в процессе понимания предметной области и всё более точного технического задания. Поэтому необходим постоянный рефакторинг в том числе и структуры
      - Минимализм
        
        На раннем этапе структура должна быть максимально простой и ей можно сформулировать в виде ОБРАЗА СИСТЕМЫ или УРОВНЕЙ РАЗДЕЛЕНИЯ ОБЯЗАННОСТЕЙ
      - Коммуникативность и самодисциплина
        
        Вся команда должна понимать структуру, которая должна быть описана на ЕДИНОМ ЯЗЫКЕ
        
        Так как структура может быть не жесткой, то у разработчиков должна быть самодисциплина, чтобы всё таки придерживаться структуры, иначе всё скатится в хаос
      - Реструктуризация даёт гибкую архитектуру
        
        Когда структура меняется - необходимо изменять всю систему. Это тяжело, но не всё так плохо :)
        
        Чем чаще обновляешь структуру - тем легче это будет сделать в следующий раз
      - Дистилляция
        
        Принципы дистилляции применимы и к крупномасштабной структур. Например изначально уровни могут быть выбраны на основании поверхностного знания предметной области, а затем количество слоёв может изменяться, как и элементы могут переходить от одного слоя к другому
  - - - Структуру (например по слоям обязаностей) можно распространить внутри одного ограниченного контекста
      - Если структура распространяется на несколько ограниченных контекстов, то один контекст (например старая система) входить сразу в несколько слоёв структуры
      - Можно в каждом контексте использовать свою структуру + структуру под набор контекстов, но тут важно соблюдать умеренность, иначе пользова от введения структуры может сойти на нет и система станет только ещё больше запутаннее
    - - Модули ЯДРА и ПЕСПЕЦИАЛИЗИРОВАННЫХ ПОДОБЛАСТЕЙ можно, например, раскидать на разные уровни структуры, делая ЯДРО ещё более понятным
    - - Начертите КАРТУ КОНТЕКСТОВ. Можно ли это сделать естесственно или есть препятствия?
        
        Существует ли на проекте ЕДИНЫЙ ЯЗЫК? Достаточно ли он богат?
        
        Обозначено ли в проекте СМЫСЛОВОЕ ЯДРО? Написано ли введение в предметную область (DOMAIN VISION STATEMENT)? Вы можете его написать?
        
        Помогают или мешают использованные технологии для MODEL-DRIVEN DESIGN
        
        Обладают ли разработчики достаточными техническими навыками
        
        Хорошо ли разработчики знают предметную область? Вызывает ли она у них интерес?
    - - Самозарождение структуры в ходе разработки
        
        Группа с хорошей самодисциплиной может начать разрабатывать структуру спонтанно и самостоятельно, хорошо если при этом обозначится неформальный лидер
      - Смежная группа по разработке архитектуры
        
        Выделение группы разработчиков для разработки архитектуры и крупномасштабных структур эффективно, но только в том случае, если они при этом непосредственно участвуют в реализации задачек наравне с остальными разработчиками
    - - Решения должны доводиться до всех членов группы
      - В процессе принятия решений следуюет учитывать обратную связь
      - План должен допускать эволюцию, развитие
      - Разработчики архитектуры не должны переманивать к себе лучшие кадлы
      - В стратегическом проектировании нужны минимализм и скромность