基于领域驱动设计的本体论
张桂权
Pavel Hruby
Microsoft
Frydenlunds Allé 6
2950
+45 29229183
张桂权 译
(未经许可不许以转载或其他任何的形式进行传播本文，否则将追究其责任)
摘要
本篇论文介绍了一种基于领域本体论应用的软件应用的领域特有模型设计的方法。我们将举例说明一个领域特有组件的应用对象可以从领域的本体论的类型中被驱动，并且应用的行为可以作为切面，应用对象的横截面，被模型化。这种方法通过模型在二维空间导向一个软件组件特有的体系结构。一维代表领域本体的类型，另一维代表用户需求功能。软件应用包含组件的内联子集和由特殊领域本体来判定的组件接口。
类型和主体描述
面向对象的编程、领域特有体系结构、领域工程、模式和数据抽象
通用术语
设计
关键字
本体、资本和事件代理（Resources, Events agents）、面向切面的编程、商业应用。
1、概述
软件设计最基本的任务之一就是创建一个应用软件对象模型。在领域特有软件设计当中，设计者有选择的应用领域知识于用户需求和面向对象设计的原则。
我们将举例说在软件设计中应用常规特有领域知识导向一个特有结构模型。模型标注两个正交关联；基础概念和源于领域知识的类型和源于用户需求的特有行为。
在这个文档中，领域驱动开发是知道在一个特殊领域或者一个应用区域的软件应用的开发。领域实例，比如，商业领域、交互系统领域、销售领域，如图2。我们叫应用模型实体为应用对象。在商业领域的应用对象是销售订单、货物清单和装运。本体类型和应用对象元类相符合，实体用来描述应用对象的特性。在商业领域中的本体类型为经济资本、事件、代理、索赔、合同和托付。应用对象的实例是应用对象运行时表现。
图1举例说明了拥有元类经济资本（本体类型）的现金应用对象。在运行时，现金实例就是一个请求对象，比如，一个钱包中的现金。
图1.本体、应用对象和实例
术语切面(**)是用来表示应用对象横截面功能性模数的一个概念。有很多手段来建模和实现横截面相关的事件，比如，面向切面的编程，组成（成分）过滤器，关联的多维分离和统一建模语言的组合。在本编论文中我们不会讨论这些任何特殊的方法，我们始终保持在概念的层次。
论文的剩余部分通过如下的结构组织：下一章概述领域组件建模的方法，接连几个章节描述方法的每一步骤。系统层次相关章节举例说明软件应用包含的基于本体接口的领域组件。论文的最后一部分回答一些作者写论文的时候收到的一些问题。
2、实现方法
本方法包含四个步骤：
1、确定领域。 这一步确定软件应用或者产品系列的范围；图2说明了
基于多重范围的领域的实例。
2、选择领域本体。有时一个合适的本体并不存在，所以必须自己开发。一个应用软件元模型可以扮演一个领域本体的角色，提供基于元模型的不知道的领域原则超乎于用户需求的及时表示。一个本体相当于包含完全领域的最小概念集合。
3、标记特殊的用户需求。经常有一些功能性需求不能成为本体的一部分，因为不是所有的领域应用都需要这些需求。我们将会展示这些需求的模型，通常是横切领域对象，而且可以作为切面被建模。
4、通过配置源于本体类型和特殊用户需求的对象构建应用模型。下一节中有这四个步骤地详细介绍。
3、确定领域
图2举例说明了应用对象在不同水平的抽象；水平线表示应用对象可以实现的领域。通用建模语言，比如，统一建模语言，是在术语对象、类和方法中描述模型，包含一些现实世界的概念的语义。另一切面，模型范围是所有面向对象系统的一个领域。特殊的建模语言是用户实体，比如，货物清单和装运包含详细的和额外的语义和模型意图信息。这种信息可以被有效的利用，比如，使模型生效而违背领域规则和领域模型之间的自动转换。这种权衡，一种特殊语言的应用性区域是比通用建模语言的应用型更加严格。
在一个理想的情况下，原型实体（modeling）必须精确的出于抽象层次（水平），即完全覆盖软件应用领域。在下一节中我们将展示处于正确抽象水平，并且符合领域类型的领域对象。比如，对于商业领域，通过资源、事件代理本体来确定符合的此类对象。
图2.抽象级别和覆盖的领域
4、领域本体
一个本体就是一个概念的详述规约[7]。本体类型定义领域中存在的概念以及概念之间的关系。对于面向对象的应用，领域本体定义这个领域中应用模型的元模型。领域类型符合应用对象的元类。比如，通过REA（资源、事件代理）来指定的经济代理是对象，如，客户和销售商，的一个元类。经济事件时销售、支付对象的一个元类。经济资本是金钱、产品对象的一个元类。同样的，本体之间的关系成为应用对象之间的关系元关系，比如，股票流是出口流和进口流之间的关系的元关系。经济事件之间的二象性是销售和支付接收之间的调和关系的元关系。
图3. 应用模型和相关的REA(资源、事件代理)元模型
5、指定需求
5.1、领域对象的功能需求
前面几节举例说明了构建软件应用可以从适用于应用的领域的本体类型驱动。虽然仅仅通过领域对象是不足以创建一个软件应用。领域对象通常需要一些本体类型没有指定，但是应用用户需求的功能。 比如，REA（资源、事件代理）本题没有指定如何确定上用对象的标识或者如何创建金融报告。然而，功能，比如，序列号和账目是商业应用用户的必需品。
应用功能没有通过领域本体来指定有一个很好的缘由。领域本体指定适用于领域内所有系统的概念结构。领域本体设法寻找最小的，仍然完全覆盖领域的概念集。
由于特定的需求，本地方便性以及其他诸多的原因，系统之间的应用对象的功能是大不相同的。比如，在商业应用中，有些对象，客户和产品，需要可读序列号；有些则不需要，比如，订单行。金融报告则与当地的法律法规有关，商业和报告的行在应用之间通常是变化的，正如不知什么原因现实世界的不同公司时不同于其他的公司的。一个完全的功能列表通常很可能没有被整个领域指定。软件应用用户经常需要新功能或者已经存在功能的新版本，而这些是本体创建者不能预见的。
5.2、横切领域对象
本体类型确定领域的一维分解。另一维分解时应用功能。在以下几段中我们将展示许多情形下应用功能组件是不能本地化到一个当一个应用对象。
在商业应用领域中，比如，产品序列号是产品对象的一个属性。序列号通常不是一个随机数。产品序列号是从一个经济资本组属性数字序列中选出来的，这些资源序列号自己提供的。因此，对象请求产品组包含指定序列号格式，一个序列号是否需要唯一，它是如何依赖于前一个产品序列号等规则，规则指定一个已经删除的产品的序列号是否可以重用，和一些相似的规则。序列号模数横切两个领域对象，产品对象和产品组对象，序列号由产品聚集部分和产品组聚集部分相互合作来构建。把这个序列号作为一个单一的模数是非常有用的，但是这个模数横切了两个应用对象。
图4.序列号横切应用对象
面向切面的编程[10]是方法之一，是一个组件方法中关于如何处理横切关联的想法的精确的约定。在领域开发的范围内，从本体类型中采用对象思考实体和利用切面理念思考软件应用功能是一种很好的想法。
这种关联区分，同时确定了一种如何在不改变基础结构的情况下增加软件应用新功能的机制。本体类型对象的协作确定的软件应用基础结构和切面提供特殊的功能。
5.3、切面类型
在介绍领域对象的章节中我们已经展示了本体类型相当于应用对象元类。类似的方法同样适用于切面范围内的实体。
在这一节中我们将为应用切面描述元类。例如，我们已经在一个应用模型中展示了序列号是一个切面。虽然，序列号的基本的目的是给应用对象提供一个为一个标识。
因此，我们可以认为序列号是一个非常通用的切面类型标识的一个特殊实例。其他的标识切面类型是名字、电话号码、电子邮件地址、统一资源定位器（URL）、全局唯一标识（GUID）和国际标准书号（ISBN）。
标识切面类型指定了给某物一个标识的概念。标识不是继承于对象和事物的一部分。人们通常用一个名字和现实或想象中的事物关联。因为在一个应用范围内名字没有必要唯一，事物可以通过给定的数字来关联。通常，现实或想象事物拥有一个或多个被给定的标识，所以可以通过这些标识与之关联。
图5. 应用切面和相关的元模型。
图5举例说明了在切面元类水平的标识切面类型和在应用模型中的序列号切面。下面我们将更加详细的描述标识切面来说明切面类型是如何被指定的。
标识切面类型在元类层次上包含两个部分：标识定义，定义一个标识类型的名称。一个标识类型含有以下的属性：AutoNumber - 一个用来指示一个标识是否可以通过系统自动的增加的布尔函数。Unique - 一个用来指示一个标识是否需要唯一的布尔函数。Mandatory是一个用来指示必须或者可以定义一个标识的布尔函数。
切面类型的Identifier部分指定标识的数据类型，比如，字符串或数字。
应用层次包含的切面部分是被设置的切面类型参数。例如，Number Series Definition是自增标识类型的一个实例。这些数字是唯一的，而且是强制的。Series Number (标识的一个实例) 包含序列中最后被利用的数字，并且明确指定标识的格式。允许序列号是数字和符号的结合体。商业领域中关于切面类型的例子是地址、账目和邮政（posting）。相关的细节，以及其他的切面类型被描述为行为的商业模式。
地址切面类型的目的，看图6，用来指定对象的地理位置以及不同位置之间的可通航的路径。地址切面由4个组件组成。起始和目标位置，实际位置决定有些应用对象的实际位置和用来跟踪实际位置历史改变的航道。起始和目的位置经常被不同的经济代理配置，航道/路径经常被不同的经济事件配置，实际位置经常被一个资源配置。
图6. 地址切面类型
邮政切面类型的目的，如图7，是跟踪有些应用对象改变时表示的交易。邮政切面的组件是持续应用对象，使之不可改变的和描述即将被每一个实体注册的信息的数字范围的实体。这些实体是典型的经济事件或交付配置，范围是通过经济代理、资源、相关类型和组所配置。
图7. 切面类型实体
账目切面类型的目的，如图8，是表示聚合的实体数据。账目切面的组件是表示聚合总额的账目和表示所有的增加或减少的一个或多个实体。账目经常通过一个代理或资源类型，和经济事件和支付实体来配置。
图8. 账目切面类型
5.4、切面类型的数字
根据我们的经验一个领域切面类型数字在某些水平上作为本体类型是很枯燥的。例如，最后一个版本的REA（资源、事件代理）本体[5]描述37个本体类型。23根据元类型，而14根据元关系。客户关系管理（CRM）商业应用的一个功能可以完全被18切面类型覆盖。
6、配置应用
我们已经展示了一个特定领域模型的二维分解：对象区域可以映射领域的本体类型，切面区域映射到为了应用的高效性而设置的行为，如图9。我们同时已经说明了可以在对象域和切面域上两个抽象水平指定的组件。本体类型或切面模式水平，和应用对象与应用切面水平。
图9. 对象、切面和领域驱动开发
图9说明了本文的主题信息，也就是，运用领域本体来确定应用对象模型引导二维正交的软件体系。
我们说明了如何利用这个基础理论在特定的领域中开发软件组件。
如果一个软件提供商在一个领域中为一个产品线的一部分开发许多应用，或开发大量的不同的应用软件，通用功能的重用时大家所希望的。本文所描述的体系允许在切面类型中实现通用应用功能，并且，也许通过配子切面类型的应用对象来开发软件应用。
应用配置模型是一种遵循特殊领域的本体，并且包含指定符合用户需求的特殊功能的模型。因为应用对象是由领域本体来确定，所以创建应用模型的过程包含为应用对象分配应用切面。这个过程如图10所示。
图10. 应用配置
图11是一个采用这种方法来配置的商业应用的例子。这个应用是一个简单销售模块的模型。这个应用中本体类型是经济代理、经济事件和经济资本，应用对象实例是客户、销售、支付、产品和现金。这个应用中切面类型是Identification (标识)、Account (账目)、Address (地址)、Posting （邮政）。标识切面的实例是Name (名称)、Item Number (产品号)、Customer Number (客户编号) 和Transaction ID(交易号)。地址切面实例是记账 Address和Shipping Address。邮政切面的实例是G/L(General Ledger)Entry和Inventory Entry（商品目录实体）。
切面类型的选择是由用户需求确定的。在软件应用中，对于销售过程的不同客户其他的配置必须包含不同的切面本体集。
图11所示的应用配置模型包含应用切面的应用对象。客户对象包含名称、编号、客户账目、记账地址和货运地址等切面。销售对象包含的切面有交易号、G/L实体。支付接收包含的切面有产品标号，而货币对象包含的切面有银行账目和现金账目。
横切两个或多个的切面应用对象的切面已经标记出来了。为了更加简洁明了，图11模型中没有标记横切，因为所举例的切面中有些需要聚合图11的应用模型中没有展示对象。例如，标识类型应该在客户号、销售、支付接收、和产品等类型中表示。货物清单对象中必须包含记账地址。由于模型会变得很大，而且为了隐藏本文中的主题，有许多对象没有呈现在图11中。
图11. 应用配置实例
7、系统体系
这种方法导致特殊领域系统的体系包含许多内部连接组件。组件的最小尺寸只受到很少的指定性限制。这种限制由本体的领域规则来驱动。比起实现技术，内部连接组件的数量没有受到任何的超级限制。其余的章节将介绍更多的细节。
由于本体设计者的目的是定义一个最小概念集合并描述相关的领域。通常含有很少数量的领域对象类型。如果一个本体定义了领域规则，这很可能确定一个很很小的领域对象类型集，而且为了满足领域规则这些类型必须在系统中表示。例如，REA本体的最小组件集合至少包含一个增加和一个减少经济事件，并而其中没一个事件包含经济资本关系和两个经济代理关系。图12说明了最小的REA组件集。如果有些对象类型或关系被遗漏掉，那么设计必须违背领域规则，由本体指定。
图12. REA最小组件集示例
图12中提供的和需求的组件接口采用UML 2.0 符号，由共享领域本体定义。例如，REA组件接口是经济资本。经济资本把相关的组件汇集到企业的价值链中，如图13所示。
图13中每一个图形化组件都有自己的潜在的不同切面集。这些组件可以由单一的ERP系统或多个协作的ERP系统模数来实现，也可以由合法的应用代替，以及相关的端口可以由特殊领域本体类型中产品的语义来传递。
图13. 一个组件系统
8、实现
基于此体系的产品已经在1999至2002期间由Navision Software公司开发。这次开发改进了本文实例概念的可行性。其中的一些概念在微软商业架构中有应用，而且是在2002以后由微软开发，在Microsoft Visual Studio的将来版本中也有应用的意向。
8.1、组成问题
所有标记横切关联配置的方法都必须回答这样的一个问题：当两个或更多的切面试图改变应用对象的相同的数据时将发生什么事情。一个最简单的方法就是回避这些问题的发生。也就是说切面类型必须设计为非重映射的、非依赖关系，并且遵循相同接口的类型允许信息交互。例如，构架的基础部分可以通过非独立切面之间交流的分析模式[2]实现。
非重射切面简单方法的序列就是，比如，如果一个电话号码既可用来客户联系，又可用来标识客户中的一员，那么电话号码域在客户对象中被两次配置：一次是地址切面的一部分，另一次是标识切面的一部分。配置应用程序可以保持着两个域的同步。数据的复写是最简化和回避组成问题的一个平衡。从概念上讲这些都是正确的，因为这些数值域对终端用户有两个语义。
如果不想用简单的方法，并且软件体系允许重射，当责成问题发生的时候，必须采用合适的方法来解决。在这种情况下，最简单的方法将把这个问题遗留给确定执行重射切面顺序的应用开发者。
8.2、面向对象的架构和特定领域语言
由于可以为一个给定的领域完美的定义切面类型和本体类型的目的和功能，这使得可以利用特殊领域应用语言来开发实现和描述类型的面向对象的架构。这这种情况下，领域特殊应用的软件开发可以减少标识应用对象和切面，并通过应用切面来装饰应用对象。
这种方法的一个正面结果，其中建模语言涵盖了整个领域，是开发软件应用所需的大量的代码在很大程度上是递减的（与采用通用语言的方法相比涵盖整个领域的语言被采纳）。
权衡在于领域特定语言仅适用于严格规定的领域，并且大多数或所有的应用都在构架中实现，这超越了来自应用开发者的影响。一个可能的妥协是允许领域特殊语言和通用语言在构架开发接口*存，所以超越构架功能范围的需求可以通过通用语言实现。
8.3、经过配置的模型是可执行的
经过配置的模型，和切面类型、应用切面、应用对象和本体类型的模型一样，包含执行模型所需的所有信息。有好多方法可以从已经配置的模型中创建可执行的应用；详细的描述超出了本文的范围。这个模型可以编译成可执行的软件，从模型中可以产生通用的代码，当编译和执行的时候[1]。这个模型也可被解释模型的构架执行，或传统的，这种模型可以作为特例，用手控开发的软件应用所利用。
9、问题和答案
这一节介绍作者在写论文的过程中所收到的/遇到的问题的答案。
9.1、在实践中这种方法提供的好处是什么？
主要的好处已经在概述和全文的讨论中提到了：领域特殊软件应用的更好的设计可以通过领域规则的遵循来证实/证明。然而，这种方法提供了其他有趣的利益含有从根本上改变领域软件开发方法的潜力。
领域变换。 如果已经描述了不同领域的本体之间变换规则，那么一个领域的应用对象可以自动的转换为另一个领域的应用对象。例如，一个用户接口（代表逻辑领域）从REA（商业逻辑领域）自动转换。相似的转换存在于商业逻辑，报告和安全，之间。功能组件通常采用手控方式开发，但是利用这种方法可以通过本体的变换规则自动的创建。
被证实的设计。如果对象和切面的类型是在面向对象的构架中实现，那么领域知识对于软件应用事有效的，并且可以应用于许多方法。例如，一个向导可以知道开发人员去利用和配置应用对象来遵循本体。一个一致性检验可以证明违背领域规则的设计。一个建模工具可以提供方框外面的领域类型的应用对象的实现。建模工作者可应用这些实现或通过增加或删除领域切面来配置它们。
健壮的设计。基于本体类型的对象和基于特殊用户需求的切面之间的关联的分离，确定系统的那些部分时稳定的，那些部分很可能需要及时的改变。只要系统仍然处于领域的边界之内，那么本体类型是不会改变的。这些切面应用配置支配用户需求的变更。
定义支配的分解。通常的面向切面的开发方法和技术，比如，哪些功能需要在作为对象进行建模和事项，哪些功能需要通过需要切面等，主题[3]依赖于开发者的直觉。在2002年OOPSLA研讨会上关于再生技术[6]的讨论展示的这个问题的答案并不清楚。这种方法给出了一个精确的答案：对象是领域本体的实体，剩下的实体聚合在切面范围内。
9.2、客户对象是如何来自本体的，而名称和地址是来自一个切面（在图11中）？
这是因为在我们采用的实例中REA本体的设计者已经使这个灵巧的讨论不包含在本体的名称和地址的类型之中。本体指定领域中所有系统中什么是公共的。切面指定软件应用的变化的功能。
在商业领域中，所有的系统都必须实现一个经济代理的一个或多个实体，在销售组件中这是客户实体。然而，REA本体没有指定任何与名字和地址相关的东西。实际上，并不是所有的实体都需要名称和地址。例如，销售订单、装运和支付接收不是经常有名称，它们经常是由序列号来区分。经济资本，如版权或股票经常没有地址。词语“经常”是很重要的，由于客户的判定可能不同，应用应该支持这样的需求。
这个问题在很大程度上也回答了本文的3.1、4.1和第6节。
9.3、应用设计是否允许增加领域对象的属性（图3）？
或，无论如何，属性词干仅源于切面？在这种方法中，切面含有两个目的。它们捕获横切关联，正如第3 节中的讨论，它们同样捕获应用对象的属性的语义。同时，在这种方法中，应用对象中源于切面的词干的所有属性，或对切面是可以访问的。如果有些属性不是切面的部分或可以被一些切面对象访问，那么这个属性的语义对于商业应用是不可知的。作为一个结果，这种方法阻止应用开发者暴露每一个用户需求属性的语义,并且为捕获这个语义的属性实现一个切面类型。
10、面向对象中新兴的语义变换表
软件应用的领域驱动开发似乎突出了当前的面向对象的思想的边界。其中的面向对象领域的专家在看完本文之后提出的一些问题，指示我们讨论一个新的语义变换表，而且领域驱动开发的过渡对于使用传统面向对象方法的人们可能是很难的。
我们所举的在软件应用的领域驱动开发中，应用设计者能用领域本体，作为创建应用模型的一种资源，结合传统的基于用户需求的分析。在领域本体中的概念化的领域知识可以作为应用模型的元模型被应用。
然而，领域本体不能描述特定的功能，并且在一个给定的领域中不用的应用之间区别，那些源于用于需求的，因为领域本体必须适用于领域中的所有的系统。源于用户需去的功能组件经常不能本地化到源于领域本体的应用对象。
为了解决这种冲突，我们举了领域特殊软件应用引导二维正交组件的体系。对象一维代表源于领域本体的类型，而切面一维代表源于用户需求的功能模型。
这种方法确定了领域特殊软件应用的软件体系，并在不改变其基础结构的情况下，允许一个给定领域的专用化和增加已存在组件的新功能。由于这种方法指定组件端口的语义，随后指定组件连接，它也在系统水平确定软件体系。
**“切面”一般也被称为“方面”。
11、参考书
[1] Czarnecki, K.Eisenecker, U.W: 《再生编程—方法、工具和应用》，Addison-Wesley，2000
[2] Buschmann,F.etal: 《面向模式的软件体系》，Wiley,1996
[3] Clarke,S,Baniasssad,E: 《主题：一种面向切面的分析和设计的方法》，ICSE 2004
[4] Geerts,G..McCarthy,W: 《企业资源、事件代理信息系统得本体论基础》, Michigan State University, August 2000
[5] Geerts,G..McCarthy,W:《延伸的企业资源、事件代理信息体系的经济的原始本体分析》，账目信息系统的国际议事录，2002，Vo1.3，pp.1-16
[6] 《模型驱动体系内容中的再生技术》，2002 OOPSLA研讨会
[7] Gruber,T.R.《可移植的本体规约的一种转化方法》，Knowledge Acquisition, 1993
[8] Hruby,P: 《通用企业模型》，in: VikingPlop 2002, Proceedings, 微软商业解决方案, 2002
[9] Hruby,P.et al: 《商业模式》，Springer-Verlag, to be published
[10] Kiczales,G..et al: 《面向切面的编程》，in: M.Aksit and S.Matsuuoka (Eds.):ECOOP’97 Proceedings,
[11] Tarr,P.Ossher,H.Harrison,W,Sutton,S.M.Jr.N: 《分离协议：关联的多维分离》，软件工程21世纪国际会议的会议录（ICSE’99）,May 1999
[12] 《UML 2.0上层结构规约》，OMG 文档 ptc/
张桂权
于清溪草堂
译者简介：张桂权,云南大学国家示范性软件2003级信息安全专业的学生。他课余主要致力于Semantic Web、Metadata、XML、Information Security、Ajax、SOA、Domain-Driven Design、Information Retrieval等方面的学习和研究。可以通过misy_world@126.com与他联系。
原文信息：
Ontology-Based Domain-Driven Design
Pavel Hruby
Microsoft
Frydenlunds Allé 6
2950 Vedbaek, Denmark
+45 29229183
phruby@acm.org
ABSTRACT
This paper suggests a method for designing domain-specific models of software applications, based on the use of domain ontologies. We will illustrate that the application objects of a domain-specific component can be derived from ontological categories for the domain and the application behavior can be modeled as aspects that cross-cut the application objects. The method leads to a specific architecture of the software component with models in two orthogonal dimensions. One dimension
represents the categories originating in the domain ontology and the other dimension represents the functional concerns that originate from user requirements. Software applications consist of an interconnected set of components, and the domain ontology
determines the component interfaces.
Categories and Subject Descriptors
Object-oriented Programming, Domain-specific architectures,Domain engineering, Patterns and Data abstraction
General Terms
Design
Keywords
Ontology, REA, Aspect-Oriented Programming, Business Applications.