Лекция
Привет, Вы узнаете о том , что такое bounded context ddd, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое bounded context ddd , настоятельно рекомендую прочитать все из категории Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend) .
Bounded Context (ограниченный контекст) - это понятие из методологии Domain-Driven Design (DDD), представленной Эриком Эвансом. DDD является подходом к разработке программного обеспечения, который акцентируется на активном вовлечении предметной области в процессе разработки.
Bounded Context - это стратегический шаблон, который помогает разделить большую и сложную предметную область на отдельные части, каждая из которых имеет четко определенные граничные условия. Это позволяет управлять сложностью и улучшить ясность и модульность системы.
В контексте DDD Bounded Context определяет область, в которой определенный термин или понятие имеет определенный смысл и контекст. В пределах каждого Bounded Context участники команды и эксперты по предметной области имеют общее понимание того, как работают различные компоненты системы и как взаимодействуют друг с другом.
Каждый Bounded Context может иметь свою собственную модель предметной области, сущности, агрегаты, сервисы, репозитории и другие элементы. Эти элементы могут быть разными в разных контекстах, но они ограничены внутри этого контекста и не пересекаются с другими Bounded Contexts.
Основная идея Bounded Context в DDD заключается в том, чтобы упростить понимание предметной области и уменьшить взаимодействие между различными компонентами, что позволяет создавать гибкие и легко поддерживаемые системы. Кроме того, ограничение контекстов позволяет разрабатывать разные части системы независимо друг от друга, что способствует масштабируемости проекта и повышению производительности разработки.
Как разбить большую систему на мелкие более управляемые компоненты? Мне часто задают этот вопрос, поэтому я собрал свои знания в эту статью.
В DDD большая система декомпозируется на ограниченные контексты (bounded contexts), которые становятся естественными границами — как микросервисы в коде и как команды в организации.
Нет способа легко и быстро определить хорошие границы bounded context. Для этого необходимо обширное и глубокое знание бизнеса и предметной области. Этот формат воркшопа разработан с учетом обеих этих потребностей и использует два инструмента для поиска наиболее эффективного дизайна системы: EventStorming и Bounded Context Canvas.
«Я разработал этот канвас в процессе проведения воркшопов по DDD на публичных мероприятиях и корпоративных сессиях. Не стесняйтесь менять его структуру, если найдете форматы, которые лучше подходят именно для вас».
Основной рецепт состоит из следующих действий:
В качестве отправной точки, я рекомендую выделить на этот воркшоп целый день. Это поможет понять, сколько времени вам действительно нужно, чтобы провести воркшоп правильно. Если собирать всех вместе дорого (трудоемко), попробуйте сразу выделить два дня, чтобы все успеть.
В идеале, участниками должны быть эксперты предметной области и технические эксперты. Если это трудно организовать, то постарайтесь, чтобы эксперты предметной области были на воркшопе хотя бы первый час.
Для проведения сессии с экспертами потребуется просторное помещение. Если вы выберете маленькую аудиторию, то скорее всего будете разочарованы результатами. Каждой группе из 4 человек понадобится как минимум 4 метра на стене.
Я опишу свою методику в свободной форме, без жесткого регламента. Однако имейте в виду:
«Мы постоянно переключаемся между пространством проблемы и пространством решения. Мы ищем информацию, создаем модель, ищем дополнительную информацию, уточняем модель и т.д.»
И еще один важный момент: цель сессии — выработать варианты и развить способность предлагать лучшие варианты в будущем.
Для проектирования системы, вам нужны две вещи: достаточно хорошее общее представление обо всей системе и достаточно глубокое понимание деталей в каждой области. Для этого начнем с EventStorming.
EventStorming — это метод совместного проектирования, позволяющий моделировать большую проблемную область от начала до конца, а также позволяющий детализировать большое число деталей там, где это необходимо.
Если вы делаете это впервые, я рекомендую выделить 1-2 часа на EventStorming. После завершения EventStorming я рекомендую разделиться на группы по 4 человека.
После того, как ваш домен смоделирован широко и глубоко на EventStorming, можно начать группировать и объединять фрагменты в bounded context.
Существует множество методов для определения bounded context. Об этом говорит сайт https://intellect.icu . Я рекомендую начать со следующих:
В первый раз потратьте не более 30 минут на это задание. Предложите группе создать исходную модель bounded context в качестве отправной точки. Она не должна быть идеальной и вряд ли будет окончательным решением.
Выходные данные должны быть оформлены списком имен bounded context на флипчарте или бумаге. Нельзя физически изменять EventStorming, если у вас несколько групп.
Возможно, вы сразу увидите несколько способов моделирования системы. Выберите пока одну из них для работы и запишите другие возможные модели (они будут полезны позже). Вы также можете понять, что вам не хватает информации о домене. Если так, проведите еще один раунд EventStorming.
Один из способов проверки правильности вашего дизайна и поиска точек улучшения — это визуализировать взаимодействие bounded contexts в полных бизнес-сценариях системы.
Если поток домена получился сложным, с большим количеством зависимостей и двунаправленными связями, значит, ваш дизайн хрупок и нуждается в дальнейшем анализе.
Существует множество методов визуализации, которые можно использовать для моделирования потоков и вариантов использования, включая диаграммы последовательности UML и диаграммы вариантов использования UML. Я советую использовать вариант доменного повествования.
При моделировании потока сообщений предметной области bounded contexts — это действующие лица в истории. Таким образом, типичная история начинается с того, что пользователь пытается достичь некоторой цели, а взаимодействие между bounded contexts направлено на то, чтобы предоставить пользователю решение.
Выдуманный пример потока сообщений домена
Моделирование стратегических потоков домена позволяет получить обратную связь по предложенным bounded contexts. Оно показывает, как контексты сотрудничают друг с другом и зависят друг от друга для выполнения полного бизнес-процесса. Это может помочь найти альтернативный дизайн.
Вопрос, который вы должны себе задавать: соответствует ли описание каждого bounded context той роли, которую он играет в доменном потоке. Если нет, то вероятно, что название или границы контекста требуют редизайна.
Поскольку ваши доменные потоки определяют отношения между bounded contexts, вы можете сразу же обнаружить очевидные недостатки дизайна. Вы можете вернуться к предыдущему действию и обновить кандидатов на bounded context или выполнить вторую итерацию EventStorming. Вы также можете записать свои мысли о дизайне и собрать больше информации о последующих действиях, прежде чем приступить к редизайну.
Следующим этапом проектирования является разработка кандидатов на bounded context, с помощью детализации ключевых критериев дизайна. Ваша команда должна выбрать bounded context, который вы считаете наиболее важным. Ограничьте обсуждение максимум 3 минутами. Не критично быть на 100% точным.
Теперь нарисуйте Bounded Context Canvas и выполните следующие шаги, чтобы заполнить детали. Я рекомендую использовать 1 лист флипчарта или бумагу аналогичного размера.
Выполнив перечисленные шаги, повторяйте процесс, пока не определите все свои bounded contexts. Постарайтесь поделить свое время поровну между выявленными кандидатами на bounded context.
Начните с определения названия вашего bounded context и его описания. Описание должно показывать цель контекста в домене и его роль в бизнесе, а не детали реализации.
Далее нужно сделать стратегическую классификацию. Является ли bounded context основной частью системы, вспомогательным элементом, общим или чем-то еще? Прочитайте пост Владика, если вам нужна помощь в выборе.
В качестве примера, заполненный Bounded Context Canvas после прохождения 1-го шага.
Если вы не можете придумать четкое название, или написать связное, точное описание, или ваши термины Ubiquitous Language (UL) неоднозначны — рассматривайте это как обратную связь для дизайна. Подумайте о перепроектировании границ или сделайте заметку и вернитесь позже (обычно лучше вернуться позже).
Теперь вернитесь к EventStorming и посмотрите на заметки для этого bounded context. Найдите наиболее важные бизнес-правила и политики, затем попробуйте выбрать 3 самые важные и добавить их на канвас.
Это также подходящий момент для поиска ключевых бизнес-слов или фраз, чтобы добавить их на канвас в раздел «Ubiquitous Language». Вы продолжите добавлять слова и фразы на протяжении всего воркшопа, сейчас это только начальная точка.
Следующий шаг — проработка возможностей, предоставляемых bounded context. Это не только проясняет то, что он делает, но и дает много обратной связи для дизайна. Вы можете задавать такие вопросы, как:
Начните определять возможности, представив публичный интерфейс. Что потребители могут запрашивать у этого bounded context и какие команды они могут вызывать? Используйте потоки доменных данных, чтобы увидеть, что нужно потребителям от этого bounded context.
Не все возможности активируются командами и запросами извне. Некоторые возможности могут запускаться изнутри. Например, запланированные задачи. Иногда вы можете заметить, что возможности объединяются в кластер, например, команда, запрос и уведомление. Если это так, соберите их вместе на канвасе и дайте кластеру имя.
У вас может появиться ощущение, что ответственность неуместна и должна относиться к другому bounded context. Если это так, выделите его с помощью какого-то опознавательного знака на стикере.
Если вам трудно определить возможности контекста или вы чувствуете, что некоторые из них отсутствуют, я рекомендую вернуться к EventStorming и более подробно смоделировать этот bounded context с фокусом на поиск возможностей, необходимых для других контекстов или служб.
Разложите каждую возможность на вашем канвасе на дополнительные возможности. Эта дополнительная детализация поможет находить альтернативные модели. Если на канвасе не хватает свободного места для деталей, найдите другой лист бумаги или пространство на стене. Вы можете пройти столько слоев вглубь, сколько сочтете нужным.
Зависимости необходимы, если мы хотим модульности, но они же вызывают широкий спектр бизнесовых, технических и социальных проблем. Поэтому важно видеть зависимости, понимать их влияние и учитывать альтернативные варианты. И поэтому последний шаг проектирования bounded context направлен на то, чтобы вы зафиксировали все ключевые зависимости вашего bounded context.
Просматривая результат EventStorming и диаграммы потоков доменных данных, определите каждую зависимость, которую имеет bounded context, и запишите следующую информацию:
Поставьте под сомнение каждую из зависимостей: нужна ли она, каковы затраты и преимущества от ее наличия. Если покажется, что без нее можно обойтись, пометьте зависимость желтым стикером.
Когда вы завершили заполнение канваса, потратьте несколько минут на то, чтобы критически оценить полученный дизайн вашего bounded context. Разбейте свои отзывы по следующим категориям:
Хороший дизайн итеративен. Прежде чем перейти к следующему bounded context, отойдите назад и посмотрите на общую картину. Вы узнали что-нибудь, что противоречит вашему дизайну? Если да, то перечертите предложенные границы, а затем продолжайте проектировать следующий bounded context.
На этом этапе спросите себя, достаточно ли подробно смоделирован домен. Было ли сложно заполнять какие-то части канваса? Если это так, попробуйте провести еще один раунд EventStorming по всему домену или в каких-то отдельных его частях.
После создания канваса для каждого bounded contexts и сбора обратной связи по дизайну, следующая часть сессии — это возвращение к исследованию. На этот раз у вас есть полный набор знаний, которые помогут найти лучшие варианты дизайна.
Результатом этого упражнения является коллекция базовых контекстных карт — визуализаций структурных взаимосвязей между bounded contexts и любые другие диаграммы, которые вы считаете необходимыми, например диаграммы доменных потоков. Каждая команда должна разработать как минимум 3 контекстные карты, каждая из которых будет показывать возможные варианты построения системы.
Пример очень точной контекстной карты, для этого воркшопа ее достаточно.
Мы проведем митап на TechLead Conf 2020, на котором разберем различные приемы, паттерны и анти-паттерны применения DDD и соберем наглядный радар. Который опубликуем после конференции.
Финальную активность можно провести в свободной форме. Цель состоит в том, чтобы пересмотреть собранную информацию и использовать ее для разработки некоторого количества дизайнов системы. В качестве отправной точки я рекомендую:
Если вы предпочитаете визуализацию этих преобразований, вам могут быть полезны следующие иллюстрации:
Чтобы завершить сессию, каждая группа должна представить подборку созданных ими контекстных карт и обсудить компромиссные моменты каждого дизайна. Нужно объяснить свой выбор, для этого обычно достаточно презентации на 5-10 минут.
Что нужно учесть в презентации:
Исследование, описанное в статье про bounded context ddd, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое bounded context ddd и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend)
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend)
Термины: Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend)