Как сбалансировать принцип DRY с минимальными зависимостями?

У меня возникла проблема с принципом DRY (Do not Repeat Yourself) и минимизацией зависимостей, которые вращаются вокруг движков правил Rete.

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

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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

So

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

Ответ 2

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