Схема инвентаризации домена - Википедия - Domain inventory pattern

Инвентаризация домена это шаблон дизайна применяется в сервис-ориентированность парадигма дизайна, приложение которого позволяет создавать пулы сервисов, соответствующие разным сегментам предприятия, вместо создания единого пула сервисов в масштабе предприятия. Этот шаблон проектирования обычно применяется, когда невозможно создать единую инвентаризацию сервисов.[1] для всего предприятия, следуя одним и тем же стандартам проектирования в различных сегментах предприятия. Шаблон проектирования инвентаризации доменов от Томас Эрл спрашивает: «Как могут быть предоставлены услуги для максимального перекомпоновки, когда стандартизация в масштабе предприятия невозможна?» и обсуждается как часть этого подкаст.

Обоснование

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

  • проблемы управления, например кому будут принадлежать сервисы и кто будет отвечать за их обслуживание?
  • организация разбросана по разным географическим точкам.
  • разные сегменты организации поддерживаются разными ИТ-отделами, и используемые технологии не совпадают.
  • некоторые сегменты организации могут быть не готовы к переходу к сервис-ориентированности.
  • необходимо провести пилотный проект только для того, чтобы убедиться в эффективности SOA.
  • в соответствии с руководящими принципами Стандартный договор на обслуживание, может быть очень сложно создать стандартизированные модели данных на предприятии.
  • культурные вопросы, например ИТ-менеджеры не желают отказываться от контроля над тем, как разрабатываются различные проекты.

Принимая во внимание вышеупомянутые факторы, гораздо практичнее создавать меньшие группы услуг, при этом область действия группы относится к четко определенной границе домена внутри предприятия.[2] Это именно то, что защищает инвентаризация доменов.[3] шаблон дизайна. За счет ограничения объема инвентаризации услуг становится проще разрабатывать группу связанных услуг и управлять ею.[4]

использование

Диаграмма А
Диаграмма А
Предприятие, состоящее из двух инвентаризаций доменов. Услуги в каждом инвентаре стандартизированы независимо в соответствии с установленными границами домена.

Чтобы применить этот шаблон проектирования, необходимо установить четко определенные границы внутри предприятия, которые обычно соответствуют определенной бизнес-области предприятия.[5] Например, отдел продаж, отдел обслуживания клиентов и т. Д. Важно, чтобы любые созданные домены относились к бизнес-доменам, поскольку это помогает поддерживать синхронизацию инвентаря услуг с бизнес-моделями по мере их развития с течением времени. После установления четко определенных границ следующим шагом будет создание набора стандартов проектирования, которые будут регулировать степень, в которой принципы сервис-ориентированного проектирования будут применяться и любые другие связанные соглашения, правила и ограничения, например как создавать модели данных, как давать названия сервисным функциям и т. д. Имея эти стандарты проектирования, можно разработать стандартизированный набор сервисов, специально настроенных для работы в рамках ограничений соответствующего сегмента организации. Поскольку услуги стандартизированы, их можно легко составлять без необходимости использования каких-либо мостовых механизмов.

Соображения

Если установленная граница домена не соответствует фактическому бизнес-домену, может оказаться трудным поддерживать такой перечень услуг из-за перекрестного управления. Каждая инвентаризация доменов теперь соответствует определенному набору стандартов, которые могут отличаться от остальной инвентаризации доменов. В результате, когда дело доходит до составления решения из сервисов, принадлежащих разным реестрам доменов, могут потребоваться какие-то механизмы преобразования, чтобы сообщения передавались между разными инвентаризациями сервисов. Например, службы в инвентаре домена A могут использовать Схемы XML которые менее детализированы по сравнению со схемами, используемыми службами, принадлежащими к инвентаризации домена B. Шаблоны проектирования, такие как преобразование модели данных,[6] Преобразование формата данных[7] и протокол мостов[8] шаблоны проектирования могут применяться для удовлетворения различных требований преобразования.[9]

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

Рекомендации

  1. ^ «Сервисный инвентарь». Архивировано из оригинал на 2010-03-13. Получено 2010-03-07.
  2. ^ Mauro et al. Стандартизированные службы устройств - шаблон проектирования для сервис-ориентированной интеграции медицинских устройств [В сети]. Дата обращения: 7 апреля 2010 г.
  3. ^ Шаблон проектирования инвентаризации домена
  4. ^ Мауро. и другие. Сервисно-ориентированная интеграция устройств - анализ шаблонов проектирования SOA. В архиве 2011-02-01 в WebCite [Online], pp. 1–10, 2010 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 7 апреля 2010 г.
  5. ^ Томас Эрл, Хербьорн Вильгельмсен Шаблон инвентаризации домена [В сети]. Дата обращения: 7 апреля 2010 г.
  6. ^ «Шаблон проектирования преобразования модели данных». Архивировано из оригинал на 2010-02-13. Получено 2010-03-07.
  7. ^ Шаблон проектирования преобразования формата данных
  8. ^ Шаблон проектирования Protocol Bridging
  9. ^ Томас Ришбек.Шаблон ESB: что такое ESB? [Online]. Дата обращения: 22 апреля 2010 г.

дальнейшее чтение

внешняя ссылка