对于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在确定任务优先级方面的作用，这点对敏捷而言也很重要。敏捷的周期很快，这也意味着，如果结合不好，那实施效果偏离原定解决方案的速度也会很快。
（五）小结：多歧路
EBA与“组合拳”的关系暂且论述到这里，总结一下：EBA最大的优势在于为“组合拳”提供企业层面的总体设计指引，这不是为了整体而整体，是为了实现整体性而整体，有了这个指引，才能更好地发挥“组合拳”的功效。但是，方法之间并非没有冲突，结合之路需要慎之又慎，如果我们当前无法像物理学家那样追逐“大一统理论”，那就让我们像Sutherland创立敏捷方法的初衷那样去实践，“当我着手开始建立Scrum时，并没有打算创造一套新的流程。我只是想汇总一下之前几十年里关于最佳工作方式的研究成果，看看都有哪些最佳做法，然后借鉴过来，效仿一下”，这其实是个很轻松的说法，知易行难。
三、聊聊中台
（一）“水深火热”的中台
“中台”概念的缘起大家都清楚，来自马云先生对一家欧洲游戏公司考察后的感悟，一个比喻。实践层面，钟华老师写的《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》是第一本比较完整地阐述阿里巴巴中台实践过程的著作，可以说是中台布道的开始吧，钟华老师如今仍在实践其理念。2019年中台可谓火的一塌糊涂，既有从原产地阿里巴巴出来的创业团队，也有将其原有实践简单包装冠以中台名号的“贴牌”者。
去年在的一次交流中，笔者曾经用Gartner曲线的形式，串起了与中台相关的书和文章，与参会者开了一个小小的玩笑，如图11所示：
彼时还没有那篇炸了圈儿的文章，笔者也无意将其补进去，毕竟这张图也只是个玩笑。任何技术形态都会经历这个历程，架构理念也不例外。有价值的自然会重新走回上升态势，哪怕是10年以后，或者像AI一样几起几落；没价值的也就寿终正寝了。Richardson 也说过：“人们往往容易被情绪因素所驱动，这也是为什么会有这么多关于技术的两极分化和过度粉饰的争论”。
中台就其设计理念而言，仍是为了有效降低系统设计复杂度、提升复用能力的企业架构方法。去年南京中台大会的闭门讨论中，主持人曾要求每位演讲嘉宾用一句话概括自己对中台的认知，笔者当时说的也是“跟我实践过的EBA相似，也只是一种架构方式”，确实，就目的而言，二者殊途同归，都是在考虑识别、沉淀企业的业务能力，将其模块化、服务化之后，更好地支持业务变化。
EBA与中台的差别，在实操层面也许主要是EBA并未考虑要将沉淀的业务能力剥离为中台层，因为EBA主张企业级复用，从这个角度讲，也不需要单独进行一个特殊的表达。EBA形成的业务组件之间按照调用的频率也可以适当进行分层，但这种分层结果并非现在中台的含义。除此之外，中台目前对企业战略如何分解落地也没有很详细的解释方法。
阿里巴巴也是业务架构理念的实践者，业务架构根据其设计范围可以区分为领域级和企业级，阿里巴巴对业务架构的应用，从其自身披露信息来看比较侧重于领域级，业务架构师按领域配置和开展工作。当然，设计发展到一定程度，总是会自然关注到企业级。
对中台的探索，笔者认为仍然值得开展下去，无论它以后还叫不叫中台，这是对架构设计理念的探索。从阿里巴巴的角度看，也是他们在技术底层实践越来越成熟之后，对上层设计的必然追求。笔者也不太赞同按照企业规模去给中台划个准入门槛，毕竟企业无分大小，只要系统建到一定规模或者数量，时间累积到一定程度，总有“技术债务”要还，总有重构的十足理由，那么作为一种架构设计理念去应用中台方法，未尝不可。如果说到成本，规模小的企业当然不必仿照阿里巴巴的方式构建昂贵的基础设施，设备成本是由系统的非功能性需求决定的，与企业的规模、财务能力也是匹配的，所谓中台烧钱，可能主要是想照搬阿里的技术方案造成的吧。抛开这个，它与一般的重构相比，是否真的会大幅度提高重构成本，笔者还是怀疑的。至于进行业务梳理的成本，只要企业想改革，这个成本无论用任何方法都是要付出的。
玄难和毗卢离职前，阿里的中台计划取名为“星环”，据说名称创意来自于刘慈欣老师的《三体》，是那艘超光速飞船的名字，对于快的追求不言而喻。但是从笔者的角度来看，倒是更喜欢美剧《无垠太空》中的“星环”，每个“星环”都是通向一个世界入口。企业自建中台需要自身的沉淀，中台产品提供商则需要行业沉淀，现实中，还需要对行业中处于不同位置或者细分领域的客户进行不同分类的沉淀，如此看，中台就像“星环”一样，是通向不同世界的入口。如果愿意再揶揄一下，走进入口，遇见的可能是“天堂”，也可能是“地狱”。
EBA也可以成为“星环”，道理是一样的。通过EBA也可以不断积累对行业或者细分领域的模型，这些模型不仅对架构设计者有所帮助，而且可能是未来走向自动化设计、AI设计的必经之路，因为AI也需要架构数据的供给才能产生设计能力，而目前架构领域连案例都经常是语焉不详、光怪陆离，更不说积累数据了。
（二）中台与“组合拳”
其实中台与“组合拳”的关系，阿里巴巴的人自己出来多讲讲会更好。从笔者的了解来看，阿里巴巴的中台实践中，“组合拳”的应用是不少的，他们的特点是一般不会强制团队使用某种方法。微服务显然是广泛使用的，敏捷开发、DDD在不同的团队中也都有应用，但是，应该不是每个团队在每次开发中都采用这些方法。
阿里巴巴的中台，据说在大规模构建之前面对的问题之一就是企业已经有上万个微服务，每次承接新需求都可能有数百个微服务受到波及，而服务数量如此之多，以至于没有人能搞清楚业务能力到底有哪些、是如何分布的，所以，搞起了业务架构，分离业务领域，理清不同领域的业务模式，再沉淀业务能力，形成中台。微服务是中台在技术层面落地的方式之一，但是中台设计要有效地为微服务的划分提供指导，并从架构层面提供业务能力的可视化，进而支持业务能力的持续优化，通过架构演进指导微服务的设计与变化。微服务则在技术落地上提升对业务能力的运维支持，提供良好的升级维护和可扩展性。
在分离业务领域方面，DDD方法也有一定范围的使用，毕竟这种方法与微服务的结合被广泛传说，而且DDD的思维方式就是侧重对限界上下文的分离，以达到在同一个限界上下文内对同一业务概念理解上的一致。每年Thoughtworks的大会上，也都有阿里人来分享应用DDD的经验。至于敏捷开发，更是常被当作互联网企业的标配。
中台跟“组合拳”的关系，其实也应该类似于本文第二部分中讨论的EBA跟“组合拳”的关系，只是现有的信息中，中台并没有像EBA那样给出一个明确的设计过程和方法，所以，分析也很难做的更深入，这并不是对着几张漂亮的架构图就可以做的比较。
