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

Question

我遇到了DRY原则的问题（不要重复自己）并尽量减少围绕Rete规则引擎的依赖关系。

大型IT组织中的规则引擎往往是企业（注意资本“E” - 这是严肃的事情）。所有规则必须表达一次，很好和DRY，并集中在昂贵的规则引擎中。一个组维护规则引擎，并且是规则集的守护者。

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

从设计的角度来看，我所面临的问题是集中规则和处理当然很好而且干，但是有成本：

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

这些问题与许多其他企业技术（例如B2B网关，ESB等）一起出现

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

我想在简单性方面犯错误，认为如果规则只能在孤立的情况下应用，那么消除依赖关系应该优先于集中化。我不确定这个论点会赢得胜利。

所以我的问题是：

1. 你在哪里看到集权与独立的论点？
2. 您对规则引擎等企业工具的体验如何？
3. 如何让隔离的论点更强大？
4. 如果我的观点不正确，你会支持集中化的论点？

Answer 1

从长远来看，整个过程的简单维护是绝对必要的。

所以DRY应该不惜一切代价，即使这会导致性能损失，一些额外的配置问题和其他“轻微”问题。

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

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

所以

1. 集中化＆gt;独立（至少在你描述的系统中）
2. 规则引擎的单一事实（同一页面上的每个人）
3. 多年后提醒他们维修费用
4. 我发现你的观点是正确的。

Answer 2

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