领域驱动设计在国有企业经营管理信息系统建设中的实践

黄崟钊

一、背景

1.领域驱动设计概述

领域驱动设计（Domain-Driven Design，DDD）由著名建模专家Eric Evans 于2003年提出，是一个针对大型复杂业务系统的领域建模方法体系。近几年，多个大型互联网企业均已在相关产品线上开展了相关实践并取得了不错的成效，也让这个只在国外流行的方法论逐渐被国内所熟知。

领域驱动设计改变了传统软件开发工程师针对数据库建模的方式，通过面向领域的思维方式，将要解决的业务概念和业务规则等内容提炼为领域知识，然后借由不同的建模范式将这些领域知识抽象为能够反映真实世界的领域模型。

2.国有企业的创新性被激发

一直以来，国有企业的“金字塔”型管理架构深受诟病。权利不断向上集中、决策周期长、员工放不开手脚，导致国有企业普遍保守、缺乏创新性，继而在市场上缺乏竞争力。

然而，近几年国家大力推进的国企混合所有制改革以及国有企业数字化转型，为国有企业注入了新的活力。一方面，国有资本和民间资本融合，双方优势互补。另一方面，互联网、大数据、云计算、人工智能、区块链等技术加速创新，大大加快了国有企业数字化转型的进程。

在此背景下，国有企业的创新性纷纷被激发，部分国有企业领导层也更愿意接受新鲜事物。为本文中提到的某国有企业通过领域驱动设计方法论来自建经营管理系统奠定了基础。

二、解决方式

1.搭建项目团队

采取“领导牵头、技术主导、全员参与”的方式搭建项目团队。

首先，由公司领导牵头，成立领导小组。领导小组由公司核心领导和联合工作组组成。公司核心领导在项目组织建立、重大业务需求决策、关键方案审议、资源保障等方面有绝对话语权。联合工作组由各部门中高层组成，负责日常事务过程中一般业务需求的决策。

其次，由研发部门选聘项目经理，协调各方开展领域驱动设计实践以及企业经营管理系统的搭建。

最后，由联合工作组确认实施小组人员名单。实施小组分为业务组和技术组。各部门应该至少安排一名业务代表，作为业务组成员，全程参与到项目建设过程中，业务代表也就是领域驱动设计方法论中的“领域专家”。技术组根据不同的专业分工，分设需求组、设计组、开发组、测试组、实施组等，组长即项目经理。

2.着手战略设计

项目团队搭建完成，即可开始战略设计。战略设计是为了降低系统复杂度，分而治之。直接面对企业经营管理这样的大业务我们可能无从下手，必须将企业经营这个大的业务拆成市场、项目、合同、开票、回款、采购、人力资源、综合事务等相对较小的业务，然后继续拆解，直至我们完全可以在一个业务范围内开展讨论与建模。“划分领域，分而治之”，是领域驱动设计的核心思想。

领域指的是范围与边界。将业务细分到一定程度后就能形成边界，在边界之内我们能建立起解决对应业务问题的领域模型。将领域进一步细分，我们就能得出“子域”。子域就是在领域内更细的业务边界与范围。

核心域、通用域和支撑域都属于子域，但他们的重要性与功能属性不同。包含企业核心业务和竞争力的子域可以划为核心域；可以同时被多个子域调用、具有通用功能的子域可以划为通用域，例如组织、员工等。除核心域和通用域之外的子域可以算是支撑域，如数据字典、消息通知等。

如何区分核心域、通用域与支撑域没有统一标准，根据企业自身特征划分即可。某国有企业经营业绩压力大，需要在营销、财务等方面发力，所以将市场、项目、财务等领域划为核心域，将人资、综合、采购等领域划为通用域。

3.开展事件风暴

战略设计完成后，需要编制事件风暴计划，按照“核心域-通用域-支撑域”的顺序，依次开展事件风暴。

事件风暴（Event Storming）类似头脑风暴，开发者与领域专家在一个足够大的白板上，使用蓝色的便签纸罗列出领域中所有的领域事件，然后使用黄色的便签纸标注出导致该事件的命令，再用绿色的便签纸为每一个事件标注出命令发起方的角色。颜色的使用可以根据使用者的习惯调整，只需要确保事件、命令、角色使用的颜色不同即可。最后对事件进行分类，整理出实体、聚合、聚合根以及限界上下文。

在开展事件风暴时，需确保本次事件风暴讨论的子域的相关部门均有领域专家到场。例如，在讨论“销售合同”时，可能涉及销售合同的签订、开票、回款、闭合等业务，那么这次事件风暴就需要业务人员、合同归口部门、财务人员至少3 名领域专家在场，以保证各方对本次事件风暴的结果达成共识。另外，实践证明，除了开发者和领域专家，系统未来的测试人员、实施人员和运维人员也需要参与事件风暴，以便于让所有人对业务的认知在同一水平线上。

4.建立统一语言

统一语言是整个项目团队在沟通交流时使用的语言。统一语言应该“确保统一，随时记录”。

“确保统一”就是说，无论你在项目团队中扮演什么样的角色，你使用的语言就必须是统一语言。很多时候，即使是“老同志”或者“部门骨干”，也会在业务流程和概念上产生分歧。当各个部门领域专家与开发者共同创建领域模型的时候，往往会引起激烈的讨论，每个人都会与其他人达成一致或者妥协，但最终都是为了创造最适合项目团队的统一语言。以该国有企业为例，在一次事件风暴过程中，业务人员、营销人员和财务人员对“项目”的定义不一致，为保证语言的统一，演化出了“销售项目”“采购项目”和“非收支类项目”等概念，并对这些概念进行了严格的释义，三方对新演化出的概念达成了一致，后续交流时大家都采用新的统一语言进行交流。

“随时记录”是指，统一语言的产生是随时可能发生的。统一语言既来源于国家标准、行业标准、公司制度，也来源于需求调研、事件风暴、日常交流。开发者需要安排专人随时记录统一语言，避免遗忘。随着时间的推移，统一语言将会不断壮大成长，成为团队的知识库。

5.完成领域建模

领域驱动设计通过领域模型同时满足分析建模、设计建模和实现建模的需要，从而将分析、设计和编码实现糅合在一个整体阶段中，避免彼此的分离造成知识传递带来的知识流失和偏差。领域模型的边界称为限界上下文（bounded context）。一个限界上下文内，所有的概念必须是清晰的，即统一语言。

开发团队在针对领域逻辑进行分析、设计和编码实现时，都在进行领域建模，产生的输出无论是文档、设计图还是代码，都是组成领域模型的一部分。

6.持续迭代优化

系统采用前后的分离架构。前端使用Vue 和ElementUI 作为开发框架，进行组件化、模块化开发；后端使用JAVA 语言，框架采用Springboo+Mybatis+Myb atisplus+RabbitMq；移动端使用uni-app 框架，组件采用uView，uni-app 可以将一套代码同时编译打包成安卓和苹果的apk/app；同时代码管理使用Git，版本依赖使用Maven 进行管理。

开发模式采用迭代开发模式。迭代式开发适合那些需求信息不明确的项目，每次只设计和实现这个产品的一部分。相对于传统的瀑布流式开发，每次设计和实现的一个阶段叫做一个迭代，每一次迭代都包括了需求分析、产品设计、开发与测试，因此每一个迭代都是一个完整的瀑布模型。在实践中，建议核心模块搭建时期、系统上线之前的迭代可根据团队默契程度定为2～4 周，系统上线后的试运行期可缩短迭代周期至1～2 周。

三、预计成效

国有企业通过领域驱动设计作为方法论，自建企业经营管理系统，预计可取得以下成效。

1.为各部门提供经营活动管理工具、日常事务处理工具，提高工作效率并通过信息系统建设，规范经营管理过程，建立经营管理过程中各环节之间数据的有效连接，实现公司经营活动的精细化管理，提升管理水平。

2.通过对数据的挖掘和分析，实现数据驱动型管理，为企业管理者提供科学的统计报表以及有效的数据可视化界面。并为企业管理者建立数据使用后评价机制，科学评估各个决策带来的影响，降低决策风险。

3.借助事件风暴、统一语言等工具，将开发人员、设计人员、领域专家对业务的认知拉到同一水平线，降低需求分析与系统设计的风险，避免系统的反复修改。通过前期的充分准备将系统建设风险前置，达到“先慢后快”的效果，提升系统开发效率。

四、经验总结

1.管理层重视是关键

企业经营管理系统是企业的主要生产经营协作工具，系统的建设是“一把手工程”。在重大事项决策以及各类事务优先级等方面，公司核心领导必须给予明确答复。另外，国有企业转型时，业务部门有很大的业绩压力，希望有更多的自由度去开拓市场，而国有企业的职能部门则经常面临网络攻防演练、上级单位巡查、审计检查等事务，更注重网络安全、合规管理以及风险控制。两者的特性决定了他们之间的矛盾是不可避免的、常态化的。在双方对业务认知冲突、争执不下时，就需要公司核心领导牵头，在二者之间寻找平衡。

2.全员参与是基础

企业的经营管理是一个多方协作的过程，系统建设过程中的需求收集、分析、评审等需要各部门全程参与，以便保障业务需求和系统需求的一致。领域专家和技术人员在一起工作，能保证开发出来的软件是能够准确传递业务规则的。无论是实践领域驱动设计，还是做好企业经营管理系统的搭建，每个部门均需要有至少1 名管理者和1～2名领域专家全程参与系统建设，不得缺失。

3.业务上的共识是核心

信息系统只是工具，在实践领域驱动设计时，更重要的是各方在业务上的共识。各部门的立场站位各不相同，推动工作要先拿共融，企业经营管理系统的搭建尤其如此。领域驱动设计的核心就是“业务驱动，而非技术驱动；业务建模，而非技术建模”，技术人员在与领域专家协作时应有意识地主导各方就每项业务达成共识。首先，各方应该就业务目标、意义、预期结果充分讨论，明确需求目的；其次，求同存异，对于达成共识的概念及时记录统一语言，对于暂时无法达成共识的地方重复以上步骤或者邀请管理层介入，逐步与各方达成共识。