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

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

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

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

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

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

去年晚些时候，Dahan曾对。

大会预计于2016年6月10日举办，现已开放注册。

查看英文原文：