Когда нужен Таксономия сервисов

При проектировании каталога сервисов уровня M3 Когда нужно определить общие черты для группы похожих сервисов Для обеспечения согласованности атрибутов и ограничений в иерархии

Когда Таксономия сервисов не нужен

Для описания конкретных технических реализаций или кода Когда сервисы не имеют иерархической связи и не наследуют свойств Для описания временных взаимодействий между приложениями

Типичные ошибки: Таксономия сервисов

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

Таксономия сервисов Service Taxonomy

На какой вопрос отвечает «Как связаны между собой различные сервисы и что они наследуют от более общих типов?»

Это иерархическая структура, в которой сервисы связаны отношением специализации. Каждый сервис в иерархии является частным случаем вышестоящего и наследует от него все атрибуты, интерфейсы и ограничения.

Аналогия Как дерево родов, где каждый потомок наследует черты и свойства от своих предков.

Разобраться

Зачем это нужно

Структурирует каталог сервисов и гарантирует согласованность характеристик через механизм наследования атрибутов, интерфейсов и ограничений от общих типов к частным.

Применить

Когда это нужно, а когда нет

Когда нужно

При проектировании каталога сервисов уровня M3
Когда нужно определить общие черты для группы похожих сервисов
Для обеспечения согласованности атрибутов и ограничений в иерархии

Когда не нужно

Для описания конкретных технических реализаций или кода
Когда сервисы не имеют иерархической связи и не наследуют свойств
Для описания временных взаимодействий между приложениями

Типичные ошибки

01Ошибочно считать элементы иерархии конкретными техническими реализациями, а не их спецификациями.
02Игнорировать механизм наследования, дублируя общие атрибуты в каждом дочернем сервисе.
03Применять таксономию к сервисам, которые не являются специализацией друг друга.

Сверить с первоисточниками

Что говорят стандарты

Определения из источников с переводом и ссылкой на раздел. Категория показывает назначение каждого подхода.

The SOV-1 specifies a hierarchy of services. The elements in the hierarchy are M3 Services (i.e. service specifications rather than service implementations), and the relationships between the elements are specialisations – i.e. one service is a special type of another. Service attributes, interfaces and constraints are inherited down a service taxonomy – e.g. if Service A is a specialisation of Service B then it also inherits all the features of Service B.

Раздел стандарта

С чем связано

Связи понятия и его место в структуре подхода.

Service Oriented Views (SOV) — сервисы как единицы работы

Связанные понятия

Понятия, которые обычно смотрят рядом с этим.

Спецификация портов систем Схема взаимодействия приложений Схема сети Таксономия способностей Текстовое описание операционного замысла Технологический прогноз Карта организации Карта потока создания ценности Карта способностей Компонент приложения Контракт

14 дней бесплатно

Опишите архитектуру своей компании в Storm

Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.

Попробовать бесплатно Без банковской карты

Это же в StormАрхитектура систем и интеграций Реестр процессов Карта бизнес-способностей