# PROCESSES Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление ARCHITECTURE Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD ANALYSIS Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux TESTING Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Генератор данных Нагрузочное DATA Ресурсы MDM Big data Об информации SQL intro MongoDB intro LIBRARY Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ: + АНАЛИЗ + Стейкхолдеры + Нотации - Сервисы | Как описать интеграцию? | Как описать сервис? АРХИТЕКТУРА ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Сервисы
latest update of the page: 09-01-2023, 21:12 UTC
Как описать интеграцию?

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

Как описать сервис?

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

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

      • (Пользователь заполняет параметры фильтрации событий. Сервис возвращает пользователю события, отвечающие параметрам фильтрации)
      • Исключительный сценарий
      • [исключительный сценарий] (Сервис возвращает ошибку, если не указаны обязательные параметры поиска данных)
  5. Нефункциональные требования
  6. Структура сервиса
    • Компонентно-логическая модель
    • Компоненты
    • Интерфейсы
    • логическая модель хранилища данных
    • физическая модель хранилища данных (описание уже на уровне БД — какие таблицы, поля, ключи и т.п.
  7. Поведение сервиса
    • здесь помещаем диаграммы последовательности (sequence diagram)
  8. Прочие аспекты сервиса
    • Сценарии отказа
      Риск Последствия отказа Компенсирующие механизмы
      Kafka Потеря логов Масштабирование