如何平衡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. 集中化>独立性(至少在你描述的系统中)
2. 规则引擎的单点事实(同一页面上的每个人)
3. 随着时间的推移,提醒他们维修费用
4. 我发现你的观点是正确的.