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

Question

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

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

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

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

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

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

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

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

Так что мои вопросы:

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

Answer 1

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

Таким образом, СУХОЙ следует выполнять любой ценой, даже если это связано с потерей производительности здесь и там, некоторыми дополнительными проблемами конфигурации и другими «незначительными» проблемами.

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

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

Так

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

Answer 2

Ваш вопрос очень специфичен для предприятий, и я больше вхожу в рабочий стол, поэтому надеюсь, что этот ответ не слишком общий. Мне понравилась концепция «Не повторяй себя», пока я не узнал, как она кодифицирована и окостенена. Мне понравилось, потому что он согласился со мной (duh!) И моими собственными идеями о том, как сделать код более удобным и менее подверженным ошибкам. В принципе, я вижу большую ремонтопригодность, поскольку требует большей части кривой обучения со стороны сопровождающего. Я не думаю, что есть простой способ. Here's an example of how to increase maintainability by a good factor, but not without a learning curve.