聚合架构：面向数字生态的构件化企业架构

纯阳书评（豆瓣:纯阳子/公众号:纯阳书评／微信号:chimbusco88）第465期《聚合架构》这本架构书籍，弥漫着集大成的气息。写书的最高境界之一，就是写到一个领域集大成的境界，而写到这个境界至少需要三重功力，一是深刻把握该领域根本问题的功力，一个领域无论如何发展，如何演绎，其根本问题和本质逻辑往往是稳定不变的，所以抓住这条领域之魂是集大成者的根基。二是洞穿领域中各流各派优缺短长的功力，在一个领域中往往会出现多种流派、众多体系，这些流派体系往往侧重领域问题的某些方面，或者是在某些方面更为突出，所以能够基于领域问题洞悉这些流派体系的长短之处之集大成者的必要条件。三是兼容并包、扬弃创新的功力，把握领域根本问题、洞察现有方法优缺短只是为集大成找到了干柴，基于问题、整合现有方法、推陈出新，把领域方法推进到高级阶段才是燃起集大成熊熊烈火的那粒耀眼火星。 第一、为什么说本书是一本弥漫着集大成的气息架构书籍。 如此评价的原因有两个，一是作者显然在企业架构领域展现出了上文中提到的三重功力。作者的企业架构系列书籍始终把技术和业务融合作为核心主题，充分展现了其深刻把握该领域根本问题的功力。作者对Zachman、DoDAF、TOGAF、FEA等架构驾轻就熟的梳理和鞭辟入里的分析，充分展现了其洞穿各流派方法论的功力。提出来的聚合架构吸收了Zachman的多视角架构、TOGAF的过程定义、DoDAF的原模型应用手法和DDD的业务与应用架构衔接方式，兼容各家之所长，体现了很强大的创新功力。 二是企业架构作为一种方法论，最好的评价还应当是实践和时间，逻辑上的评估再怎么用力也会力所不逮，正因为如此没有直接称这本书是集大成之作，而只是说本书弥漫着集大成的气息。所以说，尽管逻辑很看好，但是到底结果怎么样，还需时间和实践来回答。 第二、这本书给有志于集大成者提供了一个努力样本。 这一点绝对是本书的第二大看点。历史上众多集大成者往往只阐述自己的成果，很少向别人透露自己成功的路径和逻辑，甚至还有不少像大数学家高斯那样的人物做的更加过分，不但不肯透露而且还刻意隐瞒这一点，会像一个做了案的小偷一样，花费一番功夫把可能透露自己秘密的所有痕迹，打扫的一干二净。 作者显然大度的多，他在书中对自己的奋斗历程和努力路径进行了无保留的分享。通过他的分享，我们既可以知道他是如何在企业架构领域中不断进步，持续奔跑在通往企业架构集大成者的路上，也可以触类旁通，感悟到一条在各种领域如何不断精进并通向大成的路。其中一个秘密就是广泛阅读，大量阅读，领域内的当然要读，不读领域之内不足以知领域之过往和潮流，领域外的也要读，不读领域之外不足以知社会之过往和潮流，而不知社会难以更好的知领域，显然广泛阅读涉猎，绝对是集大成者的秘密之一。 最后，对IT人士强烈推荐本书，因为本书即使尚不足以成为企业架构领域的集大成之作，其作者也已奔跑在集大成的路上。

在找数字化转型的书时无意间读到此书。值得推荐与一读 作者是有理论、实践与教学的，这本书也是干货满满 作者也是借鉴了togaf的架构，但更注重战略、组织与业务，这是很好的思路，因为，毕竟建系统的目的就是为战略和业务服务，为人服务，，但这里的分析，我感觉组织适合放在业务之后，或者组织更多是约束条件，更影响权限管理。从某种意义上来说，做好了战略和业务层架构，甚至是功能层架构后，再去匹配组织（组织是因变量） 作者使用的方法主要是还原论、mece以及域映射，在每个域中主要关注对象、关系与规则三元素。如此，以保证最终设计的目的性与合理性，结构的同构性与一致性 这本书还有一个附属收获，就是准备做企业能力建模，不同于EA，也不同与流程，，这个切入点貌似提的人很少，，实验下，看能否成为一个企业管理的新视角与抓手

企业级架构，结合国内金融业务实战。 付晓岩两本里这本更体系化，做企业级系统的人首选。

企业架构思维是数字化转型的关键，企业架构框架是工具，可以评估一下聚合架构是不是最顺手那个[得意]。 企业架构是一种强调全局结构化思维的设计方法论，ToGAF、中台架构、聚合架构都属于企业架构，它们都在试图识别沉淀企业的核心能力，以更好地支持业务变化。

5.4　本书推荐的建模方法 传统的建模方法一般会将流程建模与数据建模分开进行，但按照本书的观点，这两个建模过程应该结合在一起，从建模分析到建模结果，都应当具有直接的联系。软件设计主要研究的是行为和数据，业务架构之所以能够成为业务与技术的桥梁，不仅因为其分析方法的结构化特征，更在于它能够阐明业务行为与业务数据之间的关系，从而与软件分析、应用设计之间建立连接。如1.4节中介绍的DDD模型一样，传统方法应当充分借鉴这种更有利于衔接业务与技术思维方式的表达方法。其实，从技术角度看待一个“构件”也是将行为与数据结合分析的，比如面向对象语言中的类、DDD中的实体、微服务中的服务等。 本书建议将现有概念下的业务架构与数据架构合并为新的“业务架构”，但是笔者也说过，这不是取消数据建模、数据模型的意思，而是将二者在建模过程中结合。 对于业务建模，笔者比较推荐BPMN方法，因为BPMN表达能力丰富，总体而言面向业务但兼具业务和技术友好性，而且BPMN的建模方法也有比较成熟的资料，学习成本较低。当然，完整的业务建模还要结合战略分析、价值链方法、用户旅程等，本书会在后续设计指南中详细介绍。 本书推荐继续以ER图表示法为主建设数据模型，在工程实践中注意加强概念级和逻辑级建模，但是目前的实践经验表明，在应用架构阶段进行数据分析时降范操作是很正常的。降范并不代表无限开放，而是要保持对数据含义理解的一致，这是在企业级范围实现有效的数据管理的基础。金融领域可以参考IBM的方法论，对于其他领域，特别是没有行业参考模型的领域，可以参照通用数据建模方法论。 相比于DDD，笔者建议继续使用传统的数据实体划分方式，因为流程模型与数据模型的配合也可以表达行为与数据结合的设计，具有“直达”应用架构的效果。从传统的数据实体切换到DDD的实体概念，例如聚合根、值对象等概念，可能会带来额外的学习成本。虽然理论上二者可以形成近似于等价的设计结果，但相对而言，传统的数据实体分析方法更利于企业级的数据管理。 笔者在此再次强调，不深入结合业务，忽视概念级、逻辑级数据模型的价值而直接进行近似于物理级的数据设计，可能是当前数据建模领域存在的主要问题，这并不需要通过“改换门庭”来解决。 ​ ​另外，笔者还想谈谈实际操作建议。 业务建模和数据建模不应分别进行，而应该同步开展，二者在模型表达上也应该结合紧密，以BPMN语法中的任务为基础，将任务中关联的数据实体在任务的描述中表达出来，并根据任务与数据的关系考虑任务边界的切分，按照“高内聚、低耦合”的原则形成边界重叠尽可能少的“构件”。 这一过程可能需要经历一定的反复甚至重构才能达到较为理想的程度，但这并不妨碍架构设计的正向开展，毕竟，任何一种架构方法设计出来的架构成果都是需要打磨的。 笔者提出的流程模型与数据模型的配合也不意味着要在建模方法上做很大的变更，方法论的发展未必是对方法论的彻底改变，更重要的是视角的调整，将可能导致分离的视角紧密结合，将不需要纠缠的视角分开。而当前我们对于数字化的关注，以及对于业务架构与应用架构衔接的关注，其实是要求我们尝试将业务架构和数据架构分离的视角整合。“一切业务数据化，一切数据业务化”，这个口号很好，但是要如何落实？笔者提出的建模思路就是一种可供参考的方法。

聚合构架按逻辑思维次序化组成体系结构设计过程。企业建立信息化规划，对信息系统建立清晰、可操作的流程、权限和职责体系，并对信息系统进行持续评估优化。

更适合咨询公司的朋友阅读，理论、总结太多，实践太少。

宏观，泛化，有些内容不太能想象到。作者画的图很不错👍

2024 第一本囫囵吞枣读完🥴，估计也是半年来第一本，缴费后有待提高(｡_｡)📖谢谢

假大空的感觉，纯理论性总结，丝毫没有介绍应用案例。