1. сначала диаграмма последовательности (sequence diagram) для согласования потоков и обсуждения подхода к интеграции с коллегами;
2. затем детализация каждого потока этой диаграммы:
   • описание атрибутного состава
   • примеры сообщений (запрос/ответ)
   • (если надо) статусную модель
   • (если надо) маппинг, например при описании ETL-процесса

Примеры сообщений (что в запросе, что в ответе, что в базе) составляются по каждому из сценариев, чтобы разработчики могли использовать их в автотестах.

Типовой шаблон страницы с описанием сервиса:

1. Команда
2. Назначение (предназначен для блаблабла)
3. Функции
   • [что сделать] (записать событие в журнал)
   • потребитель функции: [потребитель] (внешний сервис)
   • аргумент функции: [аргумент, что подаём на вход] (событие)
   • результат: [результат] (событие записано в журнал)
4. Варианты и сценарии использования сервиса
   • [use case diagram]
   • N. Сценарий [название сценария] (Сценарий Запись события в журнал)
     • Главный успешный сценарий
     • [главный успешный сценарий] (Внешний сервис ABCD передаёт событие в этот Сервис)
     
     (Пользователь заполняет параметры фильтрации событий. Сервис возвращает пользователю события, отвечающие параметрам фильтрации)
     • Исключительный сценарий
     • [исключительный сценарий] (Сервис возвращает ошибку, если не указаны обязательные параметры поиска данных)
5. Нефункциональные требования
6. Структура сервиса
   • Компонентно-логическая модель
   • Компоненты
   • Интерфейсы
   • логическая модель хранилища данных
   • физическая модель хранилища данных (описание уже на уровне БД — какие таблицы, поля, ключи и т.п.
7. Поведение сервиса
   • здесь помещаем диаграммы последовательности (sequence diagram)
8. Прочие аспекты сервиса
   • Сценарии отказа

     Риск	Последствия отказа	Компенсирующие механизмы
     Kafka	Потеря логов	Масштабирование