别再用DDD误导你的架构设计了

Domain-Driven Design（DDD) 领域驱动设计在2004年就被Eric Evans 提出。几年后，他的著作《领域驱动设计》中文版出版，在软件设计领域引起极大的反响，被无数架构师奉为架构设计宝典。

在书中，Evans将领域驱动设计分为两个阶段：以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型。由领域模型驱动软件设计，用代码来实现该领域模型。由此可见，领域驱动设计的核心是建立正确的领域模型。

区别于其他模型，领域模型的核心关键是建立一个领域并开展建模工作。但是，在现实商业业务中，没有业务的全局观领域就无从谈起。特别是面向企业数字化建设过程中，比领域模型更重要的是业务模型。业务建模才是架构设计的起点和重中之重。

对于大部分的企业和业务而言，部门或者单一业务级的软件应用已经不再是难题。但是，整合内部各业务之间，解决业务全生命周期的数字化系统是企业数字化转型或建设中面临的重要课题。

企业经营活动的开展，一般会面临市场环境、企业目标、人员组织、生产流程、销售服务等一系列的问题。其中任何一个环节没有解决好，哪怕是一次客户投诉处理不当，都能影响整个业务成败。在相对成熟的业务中，这些要素经过沉淀，更是拥有自己独特的运行规律。

面对如此复杂的因素，数字化建设要想成功难度可想而知。众所周知，数字化转型并非一蹴而就的颠覆式业务创新。它是在现有业务基础上，逐步实现全域的信息化和数据沉淀。因此，充分了解现有业务，并进行梳理、优化从而建立数字化的业务模型才是数字化建设的第一步。

业务建模（Business Modeling）是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系。它强调以体系的方式来理解、设计和构架企业信息系统。

如果说，DDD是设计建造舰载机的过程方法，那么业务建模则是建造航母前的首要任务。

正是因为经营业务中存在如此多的影响因素，在数字化业务设计中才需要利用业务建模的方法进行全方位的模型建设。

业务建模的目的是导出目标业务所需要的系统需求。在企业数字化建设中，目标业务是发生在一个企业组织内部，因此了解企业的组织结构和机制是业务建模的第一步。除此以外，了解组织的业务发生过程中存在的问题并确定改进的可能性，是业务建模极其关键的一个过程。

客户需求与设计、上线结果存在偏差甚至鸿沟，这种情况时有发生。每个阶段都会有新的桥段来嘲讽这种现象的发生，最近出现是下面的版本。

作为从业务场景向研发场景传递需求的过程，业务建模还有一个重要的目的就是确保客户、用户和开发人员达成需求共识。

基于以上目的，业务建模的主要内容包括业务组织建模、业务流程建模以及领域建模。相比于传统的软件分析设计方法，业务建模是以面向对象的方法作为工作基础。

业务建模相关的工作成果包括业务体系结构文档，补充业务规范，业务规则和业务词汇表。

业务建模的过程包含以下几个方面：

建模过程的几个基本元素包括：业务执行者、业务实体、业务用例、业务工人、业务用例实例。其中，业务执行者是指与系统交互的人的抽象类。业务实体只执行者访问、检查、操作、产生的对象。业务用例是业务执行的动作序列，并产生一个对特定业务参与者有价值的结果。

业务模型建立的基本过程，如下：

过程中最关键的识别业务用例实例和识别执行者。业务用例实例是在业务中执行的一系列动作，这些动作为业务的个体主角产生具有可见价值的结果。业务用例就是看业务为业务执行者提供了哪些价值。业务执行者达标了与业务有关的角色，此角色由业务环境中的某个人或系统来担任。识别业务执行者的过程就是识别谁在业务之外和业务打交道。

下图是业务建模中常见的用例图，是银行部分业务中的业务执行者和业务用例，以及他们之间的关系。

有了业务执行者和业务用例，建模剩下的工作就是描述业务如何工作的，也就是业务用例实现。在下图中，描述了一组向客户提供茶服务的业务用例实现。

至此，简单的业务模型就建立完成了。

可以看到，在用业务建模的方式重新描述业务的过程中，了解业务，发现业务新的机会以及用业务模型语言表达出来是关键的几个步骤。基于业务模型，再进行下一步的设计、实现架构设计以及开发实现就会变得清晰可行。

而领域驱动设计中的领域模型只是业务建模过程中一种简化认知，知识消化的方法。

关注我们，更懂架构设计