A constraint governing the use of one or more Services.
Контракт сервиса ServiceContract
На какой вопрос отвечает «Какие ограничения действуют при использовании этого сервиса?»
Это набор правил, которые определяют, как именно можно использовать один или несколько сервисов. Он задает рамки взаимодействия, ограничивая допустимые сценарии применения.
Аналогия Как инструкция к прибору, где прописано, какие кнопки нажимать можно, а какие — нельзя.
Разобраться
Зачем это нужно
Нужно для согласования ожиданий между разработчиками и потребителями сервиса. Помогает избежать ошибок при интеграции, четко фиксируя допустимые сценарии работы.
Применить
Когда это нужно, а когда нет
Когда нужно
- При проектировании взаимодействия между системами
- При описании правил доступа к возможностям сервиса
- При документировании ограничений на входные данные
Когда не нужно
- Когда нужно описать внутреннюю логику работы (берите Конфигурация способности)
- Когда важна техническая реализация соединения (берите Коннектор сервисов)
- Когда речь идет о полном цикле управления объектом (берите Конфигурация полного жизненного цикла)
Типичные ошибки
- 01Смешение контракта с описанием внутренней архитектуры сервиса.
- 02Игнорирование ограничений при создании новых сценариев использования.
- 03Создание контракта без привязки к конкретным компетенциям или ролям.
Сверить с первоисточниками
Что говорят стандарты
Определения из источников с переводом и ссылкой на раздел. Категория показывает назначение каждого подхода.
С чем связано
Связи понятия и его место в структуре подхода.
Сервисный (Services)
- Обобщение — таксономическое отношение «частное → общее»Rule
Связанные понятия
Понятия, которые обычно смотрят рядом с этим.
Опишите архитектуру своей компании в Storm
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormАрхитектура систем и интеграцийРеестр процессовКарта бизнес-способностей