Как сбалансировать принцип СУХОЙ с минимизацией зависимостей?

Question

У меня проблема с принципом СУХОЙ (не повторяйся) и минимизацией зависимостей, которые вращаются вокруг механизмов правил Rete.

Движками правил в крупных ИТ-организациях обычно являются Enterprise (обратите внимание на заглавную букву «E» - это серьезный бизнес). Все правила должны быть выражены один раз, красиво и сухо, и централизовано в дорогом движке правил. Группа поддерживает механизм правил и хранит наборы правил.

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

Проблема, с которой я столкнулся с точки зрения дизайна, заключается в том, что централизация правил и обработки, безусловно, приятна и СУХА, но есть затраты:

1. Дополнительные сетевые переходы для доступа к централизованно расположенной службе правил и возврата результатов;
2. Дополнительная сложность, если механизм правил представлен как веб-служба SOAP - потребители должны упаковать запросы SOAP и OXM получить ответ обратно в свой собственный домен;
3. Дополнительные интерфейсы между корпоративной группой, которая поддерживает механизм правил, бизнесом, который устанавливает и поддерживает правила, и разработчиками, которые их используют;
4. Дополнительная сложность - иногда может быть достаточно решения на основе данных.
5. Дополнительные зависимости - компоненты, которые не контролируют свои собственные правила, должны беспокоиться о внешних зависимостях от механизма правил для тестирования, развертывания, выпусков и т. Д.

Эти проблемы возникают при использовании множества других корпоративных технологий (например, шлюзы B2B, ESB и т. Д.)

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

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

Итак, мои вопросы:

1. Где вы попадаете на аргумент централизации против независимости?
2. Какой у вас опыт работы с инструментами Enterprise, такими как механизмы правил?
3. Как я могу усилить аргумент в пользу изоляции?
4. Если мое мнение неверно, какой аргумент вы бы высказали в пользу централизации?

Answer 1

В долгосрочной перспективе простое обслуживание всего этого будет абсолютным требованием.

Таким образом, DRY следует соблюдать любой ценой, даже если это влечет за собой потерю производительности здесь и там, некоторые дополнительные проблемы конфигурации и другие "незначительные" проблемы.

Также «независимый» отличается от «автономного».

В противном случае представьте ситуацию, когда вам нужно что-то изменить, и вам нужно связаться с множеством разных сторон, чтобы заставить их обновить. С DRY вы также решаете проблему одновременного запуска несовместимых версий в течение короткого периода времени.

Итак

1. Централизация> Независимость (по крайней мере, в описываемой вами системе)
2. Единая точка правды для механизмов правил (все на одной странице)
3. Напомните им стоимость обслуживания по прошествии лет
4. Я считаю ваше мнение правильным.

Answer 2

Ваш вопрос очень специфичен для предприятия, и я больше разбираюсь в десктопах, поэтому я надеюсь, что этот ответ не слишком общий. Мне понравилась концепция «Не повторяйся», пока я не узнал, как она кодифицируется и окостеневает. Мне понравилось, потому что он согласился со мной (дух!) И моими собственными идеями о том, как сделать код более понятным и менее подверженным ошибкам. По сути, я вижу большую ремонтопригодность как требующую больше обучения со стороны сопровождающего. Я не думаю, что есть простой способ обойти это. Вот пример того, как повысить удобство сопровождения хорошим фактором, но не без кривой обучения.