（二）EBA与DDD

方法之间的结合也是一个趋势，当然，结合是一件难度很高的事情，它的基本要求之一就是尝试结合者自己要对各个方法都有充分的了解和实践经验，并且能够让学习者可以掌握，因为对学习者而言，这意味着“1+1>2”的学习量。

EBA方法在形成业务架构解决方案之后，本身对IT实现端采用的方法没有特殊的限制性要求，这也意味着进入IT实现端的需求分析阶段后，可以尝试采用DDD方法进行细化设计，因为二者都注重数据与行为的结合，EBA方法是通过流程模型与数据模型的结合进行表达的，DDD的实体表达方式则更为直接；二者都强调通用语言，只是范围上，EBA是跨领域的通用语言，而DDD是限界上下文内部的通用语言；二者也都希望实现业务和技术两端都能理解的解决方案，也都非常关注业务含义对模型设计的影响。

但是二者也有区别，结合也有一些的困难要克服。一个比较直接的问题来自于数据模型，EBA方法注重对企业级数据模型的设计，企业级数据模型对数据治理有非常重要的作用，对大数据应用也有很直接的影响。数据模型通常的设计方式与DDD中对数据的处理有一些区别，二者在数据建模方面，对实体的定义有共同之处，比如应关注实体的业务含义，但是具体定义、实体大小的考量上，都会在实操层面有区别，而且，EBA方法比较提倡在企业层面的数据概念的抽象和统一，但是DDD是从领域出发考虑问题的，而且这个领域也不同于EBA中范围较大的领域概念，其限界上下文涵盖的范围可能很小，从而产生多个领域都有同名不同义的实体。

比如，Vaughn Vernon在《领域驱动设计精粹》一书第二章介绍的“保单”的例子，就是在承保、审核、理赔三个限界上下文中分别定义了“保单”实体，每个实体都有重复的部分和差异的部分，这样做的原因则是认为整合会造成一个过于臃肿的“超负荷”的“保单”实体。这样的实体也许大家在设计过程中也曾经遇到过，就是一个数据实体包含了过多的属性，导致数据层面没有很好地分离“关注点”。

ChrisRichardson在《微服务架构设计模式》一书的第二章中也给出了一个通过DDD处理类似问题的例子，就是对“上帝类”的拆分，“上帝类”作为全局类，可以为多个不同领域的应用调用，因而也就设计了包含不同领域的状态和行为的复杂结构，比如书中提到的“Order（订单）”，下单、送餐、付款等多个领域都会触发订单状态的转换，如果将丰富的行为打包成一个*Order数据库，会导致微服务设计方面出现“紧耦合”，微服务之间不够独立；如果只保留一个纯数据服务的Order Service，又会成为“贫血模型”。其解决之道同样也是在不同领域定义同名不同义的Order。

这两个例子其实体现了与EBA很不同的处理方式，EBA希望实现企业级的数据模型定义，也即，在企业级范围内尽可能消除同名不同义的数据实体，所以，“保单”、“订单”在EBA中通常会处理为一个而非多个实体，那么解决实体过于庞大的问题，还是要依靠对数据实体的业务含义、业务能力的识别，因为按照领域的拆分本身也会存在弊端，就是企业级数据查询与应用的困难。

对于Vernon举的例子，由于没有更多的信息，因此无法进行详细的比较，但是EBA的数据建模中，子实体的概念也可以满足不同领域的需要；Richardson举的Order的例子，在EBA方法中，很可能不会仅设计成一个庞大的Order实体，而是会拆分出客户、地址、付款单等多个数据实体，至于最后Order实体会剩多少个属性，就要看实际情况了。

但是Order这个例子中，更重要的一点是，EBA方法确实有可能会朝着设计一个*Order数据库的方向前进，因为很可能将其定义为一个Order业务能力组件，供各类业务应用进行调用，这是企业级业务能力复用的一种体现。至于这个例子中，Richardson提到的“紧耦合”问题，其实并非是Order服务变动会引起其他服务变动，而是其他服务需要修改Order模式时，会引起Order服务变动，这在EBA中，也是会出现的问题，这个问题是要辩证的看，也即，在集中设计Order业务能力组件获得的好处和引起的耦合之间进行取舍。

综上，我们可以看到，EBA可以与DDD方法进行适当的结合，但是也有在数据模型、企业级抽象目标方面的矛盾，设计方法结合的实践者必须思考操作上需要注意的问题。

如果能够有效地实现EBA与DDD结合，那对于DDD而言，找到了从企业战略分解到DDD设计的整体引导方法；对于EBA而言， DDD则对提升组件或者构件的设计效率有一定帮助。这方面的结合已经有了不错的探索者，华为的朱如梦老师写过一篇专门探讨结合方式的文章《业务架构——跨领域的统一语言》，有兴趣的读者可以参阅。

（三）EBA与微服务

其实EBA与微服务之间，笔者觉得交集主要就是在软件架构设计上，说的更直接点儿就是服务拆分上。微服务在技术实现方面自有一套落地方法，而且有Netflix成功的大规模实践。尽管通讯机制导致的复杂性也让很多人头痛不已，但是相比服务拆分这种很难找到标准的事情，还是要相对好些，所以，微服务才出现了与DDD的结合，二者都是想在一个限界上下文中，找到能够适合为之设计独立数据库的一组行为。

EBA在落地层面也需要微服务这类可以提供较大灵活性、复用性、伸缩性的实施方式，如果结合的好，二者都能够相得益彰，EBA同样也可以解决服务划分问题，而且还附赠战略落地服务。EBA方法笔者在书中曾有个改良设计方法的建议，就是吸收2003年提出的构件理论在EBA解决方案中引入构件的概念，以“乐高”积木为目标设计功能模块，这些功能模块可以成为微服务设计中需要定义的服务。

微服务的局限性之一就是该方法比较适合重构，很难在一个系统的初期设计中找到合适的设计思路，因为，微服务事实上代表着对业务更深刻的理解和精炼，实际上，笔者提出的构件设计方式也很难用在系统的首次设计上，这一点二者倒是很相似。

说到二者的矛盾之处，主要也是操作层面，类似消除“上帝类”这种对企业级抽象的不同处理思路，微服务以追求服务尽可能高的“独立性”为目标，但是实践中，耦合通常都很难完全消除；EBA更看重的是对业务能力的聚类，尽管“高内聚、低耦合”也是其设计目标，但是聚类过程中，其实比微服务设计方式更容易出现耦合问题。对于真实开发工作而言，如何处理耦合问题还是要从实际出发，不能“一刀切”地论其好坏。

（四）EBA与敏捷开发

EBA与敏捷的关系，笔者在书中曾经论述过，主要是针对“敏捷宣言”的内容。按照多数读者的第一印象来讲，恐怕都会认为EBA这种“漫长”的实施过程与敏捷主张的开发过程“格格不入”，这一点在EBA首次设计时更为明显，坦白地讲，笔者并不认为这一阶段适合敏捷，因为认识和改变一个企业的整体架构，注定是一个需要深思熟虑的过程。

敏捷开发针对的是“瀑布模型”，但是EBA并非“瀑布模型”，它是一个对企业当前状态的刻画过程，是寻找企业战略落地措施的方法，应该说，二者是不同问题空间的解域，直接比较二者并不一定合适。

此外，敏捷开发崇尚的是“轻文档”而非“无文档”，Martin Fowler认为敏捷注重的是演进式设计，而不是轻视设计；Vernon也批评一些敏捷开发实践是用“任务板挪卡”代替了设计；Sutherland在“OODA”循环中也强调掌握全景信息而非只从自身视角看问题的重要性，每次Scrum结束提出MVP，都要重走一遍循环，因为MVP就是为了获得更多、更全的反馈信息，有了这些信息才能快速决策，快速决策绝非快拍脑袋，是因为有模式加速了对信息的处理速度，这才是敏捷的原动力，也是要总结方法论的原因，“全景信息+思维模式=快速决策”。

“OODA”循环如图10所示：

与敏捷比，EBA确实是个“慢悠悠”的工作，思考的深度决定EBA的价值，因此，不给予充分的时间开展的EBA工作，无异于是在浪费时间。没必要试图用敏捷的思路去加速EBA过程，当今社会更缺乏的反倒是对企业级问题的“慢”思考。

EBA解决方案诞生后，敏捷方法可以用来促进EBA的落地过程吗？答案是肯定的，但是要让业务架构师参加到敏捷团队中，解释、修改EBA解决方案，这样才能确保实施团队充分理解作为实施前提的EBA解决方案。USPTO的例子也说明了EBA在确定任务优先级方面的作用，这点对敏捷而言也很重要。敏捷的周期很快，这也意味着，如果结合不好，那实施效果偏离原定解决方案的速度也会很快。