У меня проблема с принципом DRY (не повторяйтесь) и минимизацией зависимостей, которые вращаются вокруг механизмов правил Rete.
Механизмы правил в крупных ИТ-организациях, как правило, относятся к Enterprise (обратите внимание на заглавную букву «Е» — это серьезный бизнес). Все правила должны быть выражены один раз, красиво и СУХО, и централизованы в дорогостоящем механизме правил. Группа поддерживает механизм правил и является хранителем наборов правил.
Когда эта ИТ-организация является частью американской страховой компании, обычно действует множество правил. Существуют правила, применимые ко всем штатам и продуктам, но каждый штат имеет тенденцию разрабатывать свои собственные законы для разных продуктов, поэтому правила должны отражать эти особенности. Категорий много: актуарные, андеррайтинговые, даже для заказа кредитных и автомобильных отчетов от сторонних бюро.
Проблема, которая у меня есть с точки зрения дизайна, заключается в том, что централизация правил и обработки, безусловно, приятна и СУХА, но есть издержки:
- Дополнительные сетевые переходы для доступа к централизованной службе правил и возврата результатов;
- Дополнительная сложность, если механизм правил представлен как веб-служба SOAP — потребители должны упаковывать запросы SOAP и передавать ответ обратно в свой домен;
- Дополнительные интерфейсы между корпоративной группой, которая поддерживает механизм правил, бизнесом, который устанавливает и поддерживает правила, и разработчиками, которые их используют;
- Дополнительная сложность — иногда может быть достаточно решения на основе данных.
- Дополнительные зависимости — компоненты, которые не контролируют свои собственные правила, должны беспокоиться о внешних зависимостях от механизма правил для тестирования, развертывания, выпусков и т. д.
Эти проблемы возникают при использовании многих других корпоративных технологий (например, шлюзов B2B, ESB и т. д.).
Те же группы Enterprise также рекламируют SOA как основополагающий принцип. Но мое понимание правильного проектирования услуг состоит в том, что они должны разбивать бизнес-пространство на плитки и быть идемпотентными, независимыми и изолированными. Как сервис может быть независимым и изолированным, если его правила поддерживаются где-то еще?
Я хотел бы ошибиться в сторону простоты, утверждая, что устранение зависимостей должно иметь приоритет над централизацией, если можно показать, что правила применяются только в отдельных случаях. Я не уверен, что спор победит.
Итак, мои вопросы:
- Как вы относитесь к аргументу централизации против независимости?
- Каков ваш опыт работы с корпоративными инструментами, такими как механизмы правил?
- Как я могу усилить аргумент в пользу изоляции?
- Если моя точка зрения неверна, какой аргумент вы бы привели в пользу централизации?
