领域知识模型——企业应用系统的智慧中枢

 

作者简介：李均会，现就职于用友软件股份有限公司，任U8产品线总设计师，先后主持了多个重大版本的应用架构设计。在长达15年的研发实践中，致力于应用架构研究和实践，在动态业务建模、业务流程建模、领域模型建模等领域有丰富的实践经验。

企业应用系统有海量的领域对象和丰富的领域知识，这些领域知识一般被作为领域对象的业务逻辑或规则定义。本文认为领域知识是领域模型的一个知识切面且自成体系，结合领域驱动设计[DDD]和面向方面编程[AOP]的方法，对领域知识进行建模和应用，让面向业务活动的领域应用对象只需关注业务过程的组织和管理，用AOP技术把领域知识应用到具体的业务处理策略中，使领域应用对象和领域知识对象有更好内聚性且更轻量，不仅可大幅提升它们的可管理性和复用性，而且对系统开发效率、动态业务建模和装配能力也大有益处。

关 键 词：领域知识、领域模型、领域驱动设计、企业应用架构、DDD、AOP

1．前言

领域模型[Domain Model]和领域驱动设计[Domain-Driven Design]是目前在应用软件行业非常热门和前沿的话题，普遍认为这是构建高质量复杂系统最有效的方法和技术。领域模型在业界比较认可的定义是：领域模型是领域内的概念或者现实世界中对象的可视化表示，又称为概念模型、领域对象模型、分析对象模型，它专注于分析领域问题本身，领域对象是与技术无关的纯业务对象。领域建模的核心理念是把业务对象的属性、规则和职能封装在领域对象中，而不是被分散在用户界面层、应用层和持久化层中。

领域建模一般情况下是从应用功能或用例[Use Case]入手，因此，领域模型中的领域对象也是直接与应用功能或用例相关的业务对象，而这些领域对象模型涉及的领域知识，一般都作为领域对象的逻辑或者规则而存在。知识是应用领域问题的本质，是特定领域中一系列业务对象共有的知识切面，这个知识切面自成体系，本文中把这个知识体系的模型称为领域知识模型，与具体应用功能或者活动相关的领域对象模型称为领域应用模型。为了便于理解这些概念，我用一个与企业管理无关的通俗的例子来说明知识模型和应用模型的关系，比如对我喜欢的台球运动进行游戏建模，美式九球模型或者英式斯诺克模型是具体的领域应用模型，球台、球、球杆、运动员等是应用领域模型的核心领域对象，但要做出好玩的仿真游戏，台球碰撞中的基本物理知识是不可或缺的，用牛顿理论作为领域知识模型就涉及到质量、速度、动量等概念和动量守恒及能量守恒模型。知识模型是高度抽象并且可独立存在的模型，也是可以在各种业务情景中复用的模型，就如前面提到的台球游戏用到的牛顿理论模型，同样可以应用到保龄球游戏以及任何一款涉及到碰撞的游戏场景。企业管理领域也同样存在大量的知识模型，本文笔者致力于把企业管理领域涉及的领域知识进行分离、建模和应用的可行性分析和实践，希望以此进一步提升大型复杂企业应用系统的质量、动态业务建模和装配能力及组件复用水平。

2．企业应用系统中的领域知识问题分析

 

企业应用系统已逐渐成为企业经营管理的一体化应用平台，面向业务流程的行业深度应用和面向业务活动的作业处理成为系统核心，系统中包含的领域知识的广度和复杂度也随之成几何级数增长，系统复杂度、弹性、可靠性和开发效率都受到前所未有的挑战。为了迎接这些挑战，技术领域方面开始广泛使用动态业务建模、产业链分层、SOA等前沿技术方案；应用领域方面则积极采用领域建模方法。动态业务建模和SOA组件装配主要是面对业务流程、活动的粗颗粒业务组件或者对象。领域建模因一般从用例[Use Case]入手而导致关注的领域对象也主要是业务流程、活动涉及到的交易记录或者账务对象。如图1所示的一种普通销售业务流程包括接单、发货、开票、收款等业务环节，涉及到的主要领域对象包括销售订单、发货单、发票、收款单等交易记录对象和信用、应收、库存、可用量、收入、成本、资金等账务对象或者模型。从表面上看这是一个完整、合理的领域模型，但是当你仔细查看这些业务对象的代码细节时，你会发现各业务对象间存在大量关于产品特性、数量计量处理、金额处理、税额处理的重复代码，为了消除这些冗余代码，程序员可能采用抽象基类、抽取公共规则及其接口等设计方法，然而，遗憾的是这些方法都只是代码实现思维模式，没有领域知识模型与之对应，导致代码更加晦涩。该如何解决这个问题呢？ 

图1 一种普通销售业务流程与领域知识

 

仔细分析这些业务对象，其实不难发现它们都涉及到产品、计量、收入、成本、折扣、税、佣金等领域知识，无论企业流程和活动如何变化，这些知识的定义和逻辑是基本不变的，而且这些知识本身包含丰富的体系结构，如产品模型包括产品系列、特征、Kit件模型、ATO模型等领域知识，产品计量有包装计量、SKU计量、计价计量、特性计量、纯度计量等领域知识模型，而且这些知识模型在不同的行业或者地区中可能表现为不同的模型或规则，比如针对中国大陆工商企业增值税制度，大部分设计人员会按照图2中所示那样简单地把税额计算逻辑作为领域对象的一个规则逻辑，销售发货、发票等环节都涉及到同样的税额计算规则和计算功能，如果真的仅仅是一个简单的计算公式，就只是一个表达式计算代码的简单重复那倒无所谓了。当把税额容差处理、不同税种及其征收范围和适用条件、税制改革和国际贸易中各地区有不同税模型等都考虑在内时，图2中税额计算设计方案问题就比较突出了，而且这些问题与具体的订单、发货、发票这些业务对象显然不应该有直接关系，更没有理由因此而改变它们的代码逻辑，大家会很自然地想到把税作为领域知识对象剥离出来，这样不仅结构清晰了，而且系统应对税制变化的开发效率和弹性能力明显增强了，但同时问题也来了，何时用何种手段让订单、发货、发票这些领域对象执行这个税逻辑呢？如何管理它呢？

 

 

图 2 税额计算规则在领域对象中的常见设计方案

 

3．建立领域知识层

目前复杂的企业管理软件系统普遍使用领域驱动的分层架构，如图3左半部分所示，把系统分为用户界面层、应用层、领域层和基础设施层，根据前面

图 3 领域知识在分层架构中的层次位置

的分析，可以把应用层和领域层中领域知识分离出来建立一个独立的领域知识层，如图3右半部分所示，领域知识层的逻辑和规则和可以在领域层和应用层中使用，各层的职责如下：

 

用户界面层	负责向用户显示信息和解释用户指令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人。
应用层	定义软件要完成的任务，并且指挥领域对象来处理问题。 应用层要尽量的简单，不包含业务规则或者知识，而只是为下一层中的领域对象协调任务，分配工作，是它们相互协作。
领域应用层	负责表达业务流程和活动中业务对象的职能、规则和状态。业务对象是高度内聚的，多个业务对象通过应用层的组织来协作完成一个任务或者功能。领域应用层是业务软件的核心。
领域知识层	负责表达业务领域中业务知识相关的概念、算法、规则。业务知识是应用层中的业务活动和领域应用层领域对象应该普遍适用或者遵循的知识规律或者制度。领域知识层模型的完善度和丰富度决定了业务软件系统的应用弹性能力和应对需求变化的开发效率。
基础设施层	为上面各层提供通用技术能力：持久化、事务、上下文环境、缓存、消息通道、任务调度、UI组件等。

领域知识对象在领域知识层集中管理和建模，便于领域知识专家独立对它们进行优化和管理。企业应用系统中领域知识模型一般可以分为流程制度或业务模式、算法、规则、策略和概念或类型。从管理策略上一般遵循产业链分层体系：水平、行业、区域、个性四个层次。基础设施层提供相应的技术框架体支撑领域知识模型扩展和管理。

 

4．领域知识对象与领域应用对象之间的关系

领域知识对象或者模型是对知识的模型表达，在现实世界中一般没有实体对象与之对应，它们是现实世界中实体对象（本文称为领域应用对象）和业务活动对象完成自身业务功能中要遵循的内在知识规律，因此，领域知识对象是无状态的。最常见的设计方案是把领域知识模型中的概念对象作为领域应用对象中实体对象的值对象[Value Object]成员，或者在领域应用对象中直接调用这些领域知识对象的功能，这虽然实现了领域知识对象的封装和复用，但系统运行性能和应用策略扩展都会有较大问题。领域应用对象在不同的业务上下文环境中，如不同的业务流程和业务类型，要遵循或者应用的领域知识模型可能是不同的，比如面向订单生产[MTO]和面向对订单装配[ATO]销售接单对应的核心领域模型都是销售订单模型，仅从销售业务领域看，订单模型是相同的，但两个业务模式下销售订单中应用的产品模型却是不同的，任何商品化的企业应用系统都要同时支持这两种业务，而且还可能支持更多的业务模式（如面向订单设计[ETO]），还有，不要忘了这种业务模式相关联的特定产品模型会贯穿整个计划和生产过程。另外，同一个领域应用对象很有可能要同时应用不同的知识维度，如采购订单对象要同时受到采购订货业务模式和内控体系领域知识约束，所以，把领域知识对象作为领域应用对象的成员或者在领域应用对象的功能逻辑中直接访问都是显然不合理的。

领域知识对象的应用切入点是业务服务（Business Service）、领域服务（Domain Service）和领域实体（Domain Entity）的具体某一职能中（在业务上表现为某一个具体的业务功能），领域知识对象的行为主要表现为对领域实体对象的约束控制和计算处理，同时，这些结果可能影响业务流程后续执行策略的选择。在目前普遍采用的动态建模和组件装配的技术架构体系下，领域知识对象切入领域应用对象的定义最合适的地方应该就是业务流程策略、组件策略和业务对象策略中。如图4所示，业务策略执行器拦截领域应用对象的方法执行点后会根据切入条件创建并调用领域知识对象的应用功能，领域知识对象属性通过绑定映射访问被绑定的领域应用对象的属性，这样，领域知识就自然地根据业务上下文条件动态注入到领域应用对象职能中了。

图4 领域知识对象应用于领域应用对象上的工作原理及环境

 

  5．RBAC知识模型应用示例分析

为了更直观地理解领域知识模型对企业应用系统的影响和价值，用企业管理软件中应用普遍且不包含企业管理业务知识的例子——权限管理示例说明。权限管理目前普遍采纳的知识模型是RBAC模型，如图5所示。

 图-5 RBAC知识模型应用示例

RBAC模型包含角色[Role]、操作[Operation]、资源[Resource]三个基本概念，对角色有静态冲突[SSD]和动态冲突[DSD]约束规则，有授权分配[PA：Permissions Assignment]及控制[PC：Permissions Controlling]功能，非常简单。仅用资源为例，在企业应用系统表现为属性访问权限控制，资源可以具体化为：成本、价格、折扣、客户、供应商等等，授权分配直接针对这些概念即可，各业务对象在应用权限控制对象时，只需指定业务对象的属于与权限控制概念的绑定映射关系即可。如果没有引入RBAC知识模型，授权资源就只能直接针对领域应用层业务对象的属性，以图5中成本资源为例，一个业务对象可能有多个属性都属于成本概念，授权操作人员不得不辨别哪些属性应该归属于成本概念，但如授权操作人员是对业务知识不太精通的系统管理人员时，他只能通过查阅用户手册并和领域专家不断沟通才能完成工作，而且同样一个成本控制授权还不得不在各领域应用对象上重复上面痛苦的步骤，一般情况下至少会涉及到上百个业务对象、查询及报表对象，稍有疏忽，就可能出现系统授权控制不完整或不一致，另外，达到同样控制效果的授权数据规模也会相差巨大，相差倍数等于相关联的业务对象个数乘以相关联的属性个数，一般企业管理系统可以达到10000倍以上。

业务主管可能会用很不信任的语气问系统管理员：“就让某角色不允许查询成本信息就这么麻烦和困难吗？”。如果用领域知识模型处理该问题，系统处理就会像那位业务主管期望的那样简单和智能，只需设置某角色不允许访问成本资源就好了，一键就处理完成，而且仅产生一行授权数据，不仅处理快捷，而且系统运行效率也有天壤之别。由此可见，把领域知识从领域业务模型中分离，领域模型和系统功能更加符合现实模型和人的思维习惯，对软件开发效率、可维护性、易用性的带来的价值就不言而喻了。

 

6．总结

 

综上所述，领域知识在企业应用领域大量存在，领域知识模型可以分离到一个独立的领域知识层，独立建模、实现、管理和应用。领域知识对象注入到业务对象的技术实现是成熟可行的。企业应用系统应该提供领域知识管理平台，让领域专家可以直接在系统中创建、管理和应用领域知识模型，让系统实现领域知识的自我积累和应用，领域知识模型将成为企业应用系统的智慧中枢，丰富完善的领域知识模型也将成为企业应用系统核心竞争力的关键要素，。领域知识模型的建立和应用，对企业应用系统的开发效率、可维护性、易用性和动态建模的弹性能力都有大幅提高。

 

① 关于领域驱动设计请参考：[美] Eric Evans 著 《领域驱动设计》

②注：图中左半部分引用自 [美] Eric Evans著《领域驱动设计》中第四章（67页）

③可参考National Institute of Standards and Technology的RBAC标准