如何平衡 DRY 原则和最小化依赖关系？

Question

我在 DRY 原则（不要重复自己）和最小化围绕 Rete 规则引擎的依赖项方面遇到问题。

大型 IT 组织中的规则引擎往往是企业级的（注意大写的“E” - 这是一项严肃的业务）。所有规则都必须表达一次，既好又干，并集中在一个昂贵的规则引擎中。一个组维护规则引擎并且是规则集的维护者。

当该 IT 组织隶属于美国保险公司时，往往会有很多规则。有适用于所有州和产品的规则，但每个州倾向于针对不同的产品制定自己的法律，因此规则需要反映这些怪癖。类别很多：精算、承保，甚至用于从第 3 方机构订购信用和机动车辆报告。

从设计的角度来看，我遇到的问题是集中规则和处理当然是好的和干燥的，但是有成本：

1. 额外的网络跃点以访问位于中心的规则服务并返回结果；
2. 如果将规则引擎公开为 SOAP Web 服务，则会增加额外的复杂性 - 消费者必须打包 SOAP 请求并将响应 OXM 回他们自己的域；
3. 在维护规则引擎的企业组、设置和维护规则的业务以及使用规则的开发人员之间增加了接口；
4. 额外的复杂性 - 有时数据驱动的解决方案可能就足够了。
5. 其他依赖项 - 无法控制自己的规则的组件必须担心规则引擎上的外部依赖项，以进行测试、部署、发布等。

许多其他企业技术（例如 B2B 网关、ESB 等）都会出现这些问题

同样的企业组也将 SOA 吹捧为一项基本原则。但我对正确服务设计的理解是，它们应该平铺业务空间，并且是幂等的、独立的和孤立的。如果服务的规则在其他地方维护，服务如何独立和隔离？

我想在简单方面犯错，认为如果规则可以显示仅适用于孤立的情况，那么消除依赖关系应该优先于集中化。我不确定争论是否会赢得胜利。

所以我的问题是：

1. 您对集中与独立的争论有何看法？
2. 您在使用规则引擎等企业工具方面有何经验？
3. 如何让孤立的论点更有说服力？
4. 如果我的观点不正确，您会提出什么支持集中化的论据？

Answer 1

您的问题是针对企业的，而且我更喜欢桌面问题，所以我希望这个答案不是太笼统。 我喜欢不要重复自己的概念，直到我发现它是如何被编纂和固化的。我喜欢它，因为它同意我（呃！）以及我自己关于如何使代码更易于维护和更不容易出错的想法。 基本上，我认为更高的可维护性需要维护者更多的学习曲线。我不认为有一个简单的方法可以解决这个问题。 Here's an example of how to increase maintainability by a good factor, but not without a learning curve.

Answer 2

从长远来看，整个设备的易于维护将是绝对要求。

因此，应不惜一切代价尊重 DRY，即使这涉及到各处性能损失、一些额外的配置问题和其他“小”问题。

“独立”也不同于“独立”。

否则，想象一下当您需要更改某些内容并且您必须联系许多不同的各方以强制他们进行更新时的情况。使用 DRY，您还可以解决在短时间内同时运行不兼容版本的问题。

所以

1. 集中化 > 独立性（至少在您描述的系统中）
2. 规则引擎的单一事实点（每个人都在同一页面上）
3. 随着岁月的流逝提醒他们维护成本
4. 我认为您的观点是正确的。