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

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

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

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

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

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

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