领域知识模型

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

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

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

1.前言

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

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

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

企业应用系统已逐渐成为企业经营管理的一体化应用平台，面向业务流程的行业深度应用

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

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

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

与具体的订单、发货、发票这些业务对象显然不应该有直接关系，更没有理由因此而改变它们的代码逻辑，大家会很自然地想到把税作为领域知识对象剥离出来，这样不仅结构清晰了，而且系统应对税制变化的开发效率和弹性能力明显增强了，但同时问题也来了，何时用何种手段让订单、发货、发票这些领域对象执行这个税逻辑呢?如何管理它呢?

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

3.建立领域知识层

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

目前复杂的企业管理软件系统普遍使用领域驱动的分层架构，如图3左半部分[2]所示，把系统分为用户界面层、应用层、领域层和基础设施层，根据前面的分析，可以把应用层和领域层中领域知识分离出来建立一个独立的领域知识层，如图3右半部分所示，领域知识层的逻辑和规则和可以在领域层和应用层中使用，各层的职责如下：

用户界面层负责向用户显示信息和解释用户指令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人。