5.4　本书推荐的建模方法

传统的建模方法一般会将流程建模与数据建模分开进行，但按照本书的观点，这两个建模过程应该结合在一起，从建模分析到建模结果，都应当具有直接的联系。软件设计主要研究的是行为和数据，业务架构之所以能够成为业务与技术的桥梁，不仅因为其分析方法的结构化特征，更在于它能够阐明业务行为与业务数据之间的关系，从而与软件分析、应用设计之间建立连接。如1.4节中介绍的DDD模型一样，传统方法应当充分借鉴这种更有利于衔接业务与技术思维方式的表达方法。其实，从技术角度看待一个“构件”也是将行为与数据结合分析的，比如面向对象语言中的类、DDD中的实体、微服务中的服务等。

本书建议将现有概念下的业务架构与数据架构合并为新的“业务架构”，但是笔者也说过，这不是取消数据建模、数据模型的意思，而是将二者在建模过程中结合。

对于业务建模，笔者比较推荐BPMN方法，因为BPMN表达能力丰富，总体而言面向业务但兼具业务和技术友好性，而且BPMN的建模方法也有比较成熟的资料，学习成本较低。当然，完整的业务建模还要结合战略分析、价值链方法、用户旅程等，本书会在后续设计指南中详细介绍。

本书推荐继续以ER图表示法为主建设数据模型，在工程实践中注意加强概念级和逻辑级建模，但是目前的实践经验表明，在应用架构阶段进行数据分析时降范操作是很正常的。降范并不代表无限开放，而是要保持对数据含义理解的一致，这是在企业级范围实现有效的数据管理的基础。金融领域可以参考IBM的方法论，对于其他领域，特别是没有行业参考模型的领域，可以参照通用数据建模方法论。

相比于DDD，笔者建议继续使用传统的数据实体划分方式，因为流程模型与数据模型的配合也可以表达行为与数据结合的设计，具有“直达”应用架构的效果。从传统的数据实体切换到DDD的实体概念，例如聚合根、值对象等概念，可能会带来额外的学习成本。虽然理论上二者可以形成近似于等价的设计结果，但相对而言，传统的数据实体分析方法更利于企业级的数据管理。

笔者在此再次强调，不深入结合业务，忽视概念级、逻辑级数据模型的价值而直接进行近似于物理级的数据设计，可能是当前数据建模领域存在的主要问题，这并不需要通过“改换门庭”来解决。

另外，笔者还想谈谈实际操作建议。

业务建模和数据建模不应分别进行，而应该同步开展，二者在模型表达上也应该结合紧密，以BPMN语法中的任务为基础，将任务中关联的数据实体在任务的描述中表达出来，并根据任务与数据的关系考虑任务边界的切分，按照“高内聚、低耦合”的原则形成边界重叠尽可能少的“构件”。

这一过程可能需要经历一定的反复甚至重构才能达到较为理想的程度，但这并不妨碍架构设计的正向开展，毕竟，任何一种架构方法设计出来的架构成果都是需要打磨的。

笔者提出的流程模型与数据模型的配合也不意味着要在建模方法上做很大的变更，方法论的发展未必是对方法论的彻底改变，更重要的是视角的调整，将可能导致分离的视角紧密结合，将不需要纠缠的视角分开。而当前我们对于数字化的关注，以及对于业务架构与应用架构衔接的关注，其实是要求我们尝试将业务架构和数据架构分离的视角整合。“一切业务数据化，一切数据业务化”，这个口号很好，但是要如何落实？笔者提出的建模思路就是一种可供参考的方法。