Post #888

Если вам удобнее использовать Canvas — для микросервисов есть и он, конечно. Точнее, даже не для самих микросервисов, а для ограниченных контекстов (спасибо Денису Мигулину за наводку). Разделы: Название Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы. Стратегическая классификация, из трех частей: 💎 Уникальность — насколько этот контекст важен для успеха организации? Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического? ⚙️Роль в бизнес-модели: — генерация прибыли, — повышение вовлеченности/виральности, — предотвращение рисков (регуляторных, репутационных, ...) — снижение расходов 📊Стадия эволюции (по Wardley map): — Зарождение — Заказная разработка — Готовый продукт — Типовое решение (commodity) Архетип домена (роль): — Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта) — Исполнитель (выполняет или поддерживает исполнение бизнес-процесса) — Аудитор (отслеживает выполнение) — Контролер (принимает решение о возможности выполнения следующего шага, утверждает) — Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами) — Переводчик (переводит между разными "бизнес-языками") — Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика) — Пузырь (экранирует легаси-систему до её вывода) — Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой) — Аналитика (собирает и обобщает данные) Язык домена: какие в этом контексте есть понятия и термины? Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события. У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста: — OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст. — CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream. — ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне. — SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание. — PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться) — Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития. — PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR. По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне. Так же заполняется часть с исходящими коммуникациями, только теперь наш контекст будет upstream. Входящие и исходящие коммуникации удобно группировать в дорожки — юскейсы. Бизнес-решения: какие приняты решения, политики и бизнес-правила. Предположения: какими бизнес-предположениями в отношении контекста мы руководствовались. Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех? Открытые вопросы: что ещё нужно выяснить? Я не знаю, как это заполняют программисты, но, кажется, это типовые вопросы для аналитика. Причем даже без связи с DDD, такие вопросы стоит задать при работе над любой задачей.