转载

Udi Dahan对于业务逻辑重用以及微服务方面的观点

今年的 DDD Exchange 大会在伦敦如期举行, Udi Dahan 在大会上的一场 演讲 中从一种不同的角度对业务逻辑进行了剖析。他表示:近三十年来,重用已经成为了一种口号,它几乎可以套用在系统开发中的每一个环节上。但重用其实是一种砒霜,极少量的使用可以用于治疗,而一旦过量就会致命。

Dahan是SOA与DDD方面的业界权威,他首先描述了重用思想的发展。当面向对象思想开始流行之时,重用的概念在其中扮演了一个重要的角色,但在实际应用中由于对象结构层次的使用没有得到良好的制约,导致出现了大量的紧耦合问题。在那段时间之后的5至10年内,面向组件的设计开始冒头,它着重承诺了可重用组件的地位,但重用还是没能成为拯救我们的灵丹妙药。随后在软件设计中又出现了SOA与微服务技术,它们都着重强调了重用的重要性。但经过了这些年的经验之后,Dahan抛出了这个疑问:如果重用从没有真正地起到作用,又怎能期望它会在当下创造奇迹呢?

将重用视为一种糟糕的主意,这种看法并不鲜见。Dahan在这里引用了Ted Neward的思想,后者在 企业计算十大谬误 的基础上又额外补充了一条: 业务逻辑能够、也应该实现集中化 。Dahan以一个简单的规则为例:某种名称必须限制在40个字符之内。那么应当在哪里强制实施这一规则呢?通常来说,我们一般会在UI、业务逻辑以及数据库中实现这一规则,但由于实现规则的地方不止一处,一旦这条规则需要改变,问题就出现了。Dahan曾经看到过这样一种解决方案,即通过元数据生成代码,这意味着只需在一个地方改变这条规则,就能够自动重新生成修改后的代码。但以他的经验来看,这种做法多半不会成功。从根本上说,问题不在于这条规则在多个地方实现,而在于难以找到所有能够改变这一规则的地方。Dahan提出了一种解决方案,他建议使用源代码控制处理这一问题。首先为这一规则创建一个issue,然后将所有用于处理这一规则的源代码进行一次整体提交,并将它与这个issue相关联起来。如此一来,一旦需要改变这一规则,很容易就能够找到实现这一规则的所有代码:

当某条规则改变时,就到源代码控制系统中去找

软件架构并非一种简单的二维问题,不可能通过一个简单的图描述一个完整的架构。Dahan引用了 Philippe Kructhen 所提出的 4+1架构视图模型 ,Philippe认为将整个架构简化为一个单一的视图是不可能的,必须将架构的不同方面封装在不同的视图中,才能够处理所有的复杂性。在Dahan看来,微服务思想的一个问题在于它试图以同一种视图表现所有环节,开发、逻辑、过程乃至硬件单元都被压缩在一个单一视图之内,他认为这会使服务的约束显得过于沉重。

Dahan认为以下场景是比较适合使用微服务的:当你需要测试新的某个业务用例,需要进行快速开发,并且可以独立地部署该方案的实现时,此时就是使用微服务的良机。但他同时也提到,一旦证实了这一业务用例能够正常运作,对原始的实现进行重写是十分重要的,而且必须事先征求业务人员的同意。

去年晚些时候,Dahan曾对 微服务在企业中的应用进行了一次具有批判性的审视 。

明年的DDD Exchange 大会预计于2016年6月10日举办,现已开放注册。

查看英文原文: Udi Dahan on Reuse in Business Logic and Microservices

正文到此结束
Loading...