Если вам удобнее использовать 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, такие вопросы стоит задать при работе над любой задачей.