（计算机科学与技术专业论文）领域驱动设计方法的研究及在电信数据采集平台上的应用.pdf

东北大学硕士学位论文 摘要 领域驱动设计方法的研究及在电信数据采集平台上的应用 摘要 复杂的网络结构和各异的数据采集方法为网管平台的数据采集工作提出了挑 战，如何有效地控制业务领域本身的复杂性是实现网络管理系统的一个核心问题， 领域驱动设计方法为解决复杂的软件业务逻辑提供了应对之道。 本文研究了领域驱动设计方法，并使用该方法对电信数据采集平台进行了设 计和实现。首先通过了解领域建立简单模型，与领域专家一起细化、精炼和重构 领域模型，直至得到深层模型。其次，划分平台的核心领域和通用子域，以便迸 一步优化核心模型和确定开发优先级。然后，以创建和实现的电信数据采集核心 模型为基础，加上划分的通用子域，结合成熟的体系结构风格对数据采集平台的 整体进行设计。最后，主要实现了模型的相关部分，包括常用的几种数据采集协 议、s q l l o a d e l 数据加载等，并且使用配置文件达到平台的灵活性和通用性。 本文创建了数据采集深层模型，组织了领域中的关键知识，并将其作为数据 采集平台设计和实现的基础，具有很好的技术灵活性和实践应用效果。 关键词：领域驱动设计；电信数据采集；简单模型；深层模型 东北大学硕士学位论文a b s t r a c t o nm e t h o do fd o m a i n d r i v e nd e s i g na n d a p p l i c a t i o n t he r e o fi np l a t f o r mo fd a t a a c q u i s i t i o ni nt e l e c o md o m a i n a b s t r a c t 1 f 1 碡d a t aa c q u i s i t i o ni sc h a l l e n g e db yt h ec o m p l i c a t e dn e t w o r ka r c h i t e c t u r ea n d t h ev a r i a b l ea n dd i v e r s em e t h o do fd a t aa c q u i s i t i o n i ti st h ek e r n e lr a a t t e rt h a th o wt o c o n t r o lt h ec o m p l e x i t yo fd o m a i n t h em e t h o do ft h ed o m a i n - d r i v e nd e s i g nt a c k l e st h e c o m p l e x i t yi nt h eh e a r to f s o f t w a r e t l l i sp a p e rm a i n l ys t u d i e sa n dr e s e a r c h e so nt h em e t h o do f d o m a i n - d r i v e nd e s i g n a n df u g t h e re n d e a v o r st oa p p l yt h i sm e t h o di n t ot h ed e s i g no fp l a t f o r mo fd a t a a c q u i s i t i o ni nt e l e c o md o m a i n f i r s t l y ，f o rt h ep u r p o s et og e td e e pm o d e l ，i tb u i l d s m o d e lw i t hd o m a i ne x p e r t st h r o u g ht h eb u i l d i n go fs i m p l em o d e li nt e r m so ft h e u n d e r s t a n d i n go nd o m i a n s e c o n d l y ，i td i s t i n g u i s h e st h ec o r ed o m a i nf r o mg e n e r i c s u b - d o m a i n t h i r d l y i td e s i g n st h ep l a t f o r mo nt h eb a s i so fd e e pm o d e lt o g e t h e rw i t l l g e n e t i cs u b - d o m a i na n ds o f t w a r ea r c h i t e c t u r ep a t t e r n f i n a l l y ，t h i sp a p e rm a i n l ya i m st o r e a l i z et h er e l e v a n tp a r t so ft h em o d e l ，i n c l u d i n ga c q u i s t i o na g r e e m e n t ，d a t al o a d i n g a n ds oo n m o r e o v e r , t h eu s eo ft h ec o n f i gf i l e sm a k et h ep l a t f o r mf l e x i b l ea n d u n i v e r s a l t h i sp a p e rb u i l d sd e e pm o d e lo fd a t aa c q u i s i t i o ni nt e l e c o md o m a i n , o r g a n i z e s t h ek e yk n o w l e d g eo ft h ed o m a i n , a n df i l l sw i t hf l e x i b i l i t ya n de f f e c t i v ef u n c t i o nf o r d e s i g n i n gt h ep l a t f o r m o nt h eb a s i so f t h em o d e l k e yw o r d s ：d o m a i n - d r i v e nd e s i g n ；d a t aa c q u i s i t i o ni nt e l e c o md o m a i n ；s i m p l em o d e l ； i i e e dm o d e l i 独创性声明 本人声明所呈交的学位论文是在导师的指导下完成的。论文中取 得的研究成果除加以标注和致谢的地方外，不包含其他人己经发表或 撰写过的研究成果，也不包括本人为获得其他学位而使用过的材料。 与我一同工作的同志对本研究所做的任何贡献均己在论文中作了明确 的说明并表示谢意。 学位论文作者签名：龚畅 日期：2 0 0 上j2 ， 学位论文版权使用授权书 本学位论文作者和指导教师完全了解东北大学有关保留、使用学 位论文的规定：即学校有权保留并向国家有关部门或机构送交论文的 复印件和磁盘，允许论文被查阅和借阅。本人同意东北大学可以将学 位论文的全部或部分内容编入有关数据库进行检索、交流。 学位论文作者签名： 日期： 另外，如作者和导师不同意网上交流，请在下方签名；否则视为 同意。 学位论文作者签名：囊畅 签字日期：2 0 0 7 2 1 2 导师签名：苏聃红 签字日期：歹7 乒，j 东北大学硕士学位论文第1 章绪论 1 1 背景及意义 第1 章绪论 随着运营商网络、业务的多样性，技术的复杂性，设备的异质性，以及运营 商网管的建设远落后于网络的建设，网络管理的建设已是摆在运营商面前刻不容 缓的任务。目前国内几大运营商都是综合业务运营商，电信、移动、联通、网通 等分别有自己的数据网、话务网、传输网络等多个专业网络，为了保障这些网络 高效、高质量、高效益的运行，运营商的基本做法是分网分期建设，每添加一次 硬件设备，建设一期专网网管【1 1 。不同厂商的设备都附有各自的网元级网管，这 些不同的设备组成了繁多复杂的网络环境，每一个网元之间无法建立联系。导致 专业人员无法从整体上对运营商的网络进行监控。 当市场竞争越来越激烈、网络越来越复杂、越来越难于管理时，网络运营商 和网络管理人员就越需要一个功能强大的网络管理系统，通过一个操作终端去监 控所有网络，降低成本，提供效率，通过计算机来解决复杂的网络管理，所以各 大运营商提出几乎同样的目标：降低网络运营，降低网络运营管理成本，快速提 供业务，保证网络质量：对所有网络进行集中操作、集中维护、集中管理。 数据采集是整个网络管理生产平台进行网络管理的基础和前提。复杂的网络 结构和各异的数据采集方法为网管平台的数据采集工作提出了挑战。如何有效地 控制业务领域本身的复杂性是实现网络管理系统的一个核心问题。 领域驱动设计方法，提供一种思路，一种方法，它能很好地控制软件核心的 复杂性，它能有效地加快软件项目的开发速度，并指导从混乱和复杂的领域中找 到秩序和规律，抽象出一套通用语言，并通过恰当地运用一系列模式和策略来发 挥通用语言的巨大作用。 同时，现在的软件部门一般都是长期针对某个行业做应用解决方案，大部分 部门都会有一定的领域积淀，所以研究如何有效地利用这些资源进行软件设计和 如何更好的复用这些资源是非常有意义的。 1 2 研究状况 需求的多变性是无庸置疑的，尝试通过需求管理、需求跟踪等管理方式约束 和减少需求频繁更新带给软件的冲击，只会使得软件更加僵化，程序员更加疲惫。 需求不但多变，而且经常是不可能第一次就能掌握，需求反映了某个领域的 东北大学硕士学位论文 第1 章绪论 专业知识，例如数学、管理、财务或电子商务等等，每个特定案例需求又有其特 别复杂之处，几乎没有人能够第一次接触就可以深入掌握这些专业领域的需求本 质，就是专门的建模专家也不例外。 既然需求是多变而且复杂的，所以，就不能使用“堵”式方法对其进行控制 和管理，只能顺势而为，通过灵活多变的以及迭代反复的方式逐步抓住需求，并 且软件系统必须能够迅速应对需求变化，需求变化有多快，软件变化就有多快。 因此，对于多变的需求，解决方法是：引入灵活多变的架构，面向对象架构 正是应对多变需求而生，强调软件的可维护性和拓展性，面向对象可能不是最好 方式，但是目前是最合适的；对于复杂的需求，需要委派专门的建模专家跟踪、 理解需求，在需求和需求实现之间搭建桥梁，软件开发采取迭代的敏捷开发方式， 逐步了解、学习、掌握需求。 在应对需求和软件设计的方法演变过程中，大致经历了三个阶段。 ( 1 ) 围绕数据库的驱动分析设计，新软件项目总是从设计数据库及其字段开 始，这个阶段特征就是围绕数据库编程。 围绕数据库分析和设计的缺点非常明显：首先，不能迅速有效全面认识和反 映需求，真实的世界不只是由简单的关系数据组成，而且使用关系数据来反映现 实需求，不符合人类自然思维，是一种扭曲的分析方法。 围绕数据库分析极其容易导致过程化设计编程，数据库结构确立后，开发人 员开始编写s q l 语句，s q l 语句执行有明显的先后顺序，在这样顺序过程的编 程思维中，面向对象思维就难以生存。长此以往，成为习惯后，就很难改变到面 向对象设计上，所以，传统编程经验越丰富，转变到面向对象设计就越难。 在运行性能方面：围绕数据库分析设计容易导致软件运行时负载集中在数据 库端，系统性能难于扩展，容易走上集中式、昂贵的、高风险的大型机模式口1 ， 闲黄了中间件j 2 e e 服务器分布式集群处理能力，就是使用了集群，负载效果也 不明显。 ( 2 ) 面向对象的分析设计方法诞生后，使用u m l 符号来表达分析设计思想， 分析设计进入了一个相对更高的层次，拥有了自己一套相对科学的方法论。但是 有一个致命缺点：分析阶段和设计阶段是断裂的，互相不能很好衔接。 其中，分析人员的职责是负责从需求领域中收集基本概念，而设计人员的职 责是必须指明一组能在项目中适应编程工具构造的组件，这些组件必须能够在目 标环境中有效执行，并能够正确解决应用程序出现的问题。所以，两个阶段两者 目标不一致，分析人员只管需求分析，至于是否适合设计，或者能够导出适宜设 计的分析结果，这个尺度很难衡量和把握；而设计人员因为照顾代码的可运行， 2 东北大学硕士学位论文第1 章绪论 因此，经常可能会抱怨分析员给出的结果过于粗糙，不适合设计。这种分析和设 计两个阶段分裂性，很有可能导致项目失败。 在这个阶段，虽然有u m l 帮助，但是u m l 不是思想【3 】，正如会c a d 的绘 图员不是建筑师，同样，u m l 并不等于分析设计思想。 ( 3 ) 融合了分析阶段和设计阶段的领域驱动设计( d o m a i n d r i v e nd e s i g n ) 。 2 0 0 4 年e r i ce v a n s 发表d o m a i n - d r i v e nd e s i g n t a c k l i n gc o m p l e x i t yi nt h eh e a r to f s o f t w a r e ，阐述了领域驱动设计【4 j 。 领域驱动设计方法，是软件核心复杂性应对之道，它抛弃了分裂分析模型与 设计的做法，使用单一模型来满足这两方面的需求，这就是领域模型。单一的领 域模型同时满足分析原型和软件设计，如果一个模型实现时不实用，重新寻找新 模型。如果模型没有忠实表达领域关键概念时，也必须重新寻找新的模型。建模 和设计成为单个迭代循环。这样，领域模型和设计就会紧密联系在一起。 曾经有需求专家呼吁：最好将需求让所有开发人员都了解，需求专家和开发 人员一起工作，这些想法的本身是好的，但可实施性比较小。所有的开发人员不 但要了解软件架构和面向对象思想，同时还需要掌握另外一个专业的领域知识， 是不太现实的。而且团队成员的流动也是很普遍的现象，人员流动也意味着领域 知识的流失。所以，正确的方式是应该让团队中核心的、稳定的开发人员学习领 域知识，和领域专家一起建立领域模型，并负责系统中核心领域部分，而其他开 发人员可以借助模型方便地学习领域知识，开展自身工作。 1 3 本文的内容和组织 本文主要研究了领域驱动设计方法，并使用该方法对电信数据采集平台进行 了设计和实现。领域驱动设计是一种软件设计方法，它强调由领域专家和软件设 计人员共同创建领域模型。电信数据采集是进行网络管理的基础和前提，复杂的 网络结构和各异的数据采集方法给数据采集工作提出了挑战。领域驱动设计方法 为解决复杂的软件业务逻辑提供了应对之道。本文运用领域驱动设计的一些模式 和策略，创建和实现了电信数据采集模型，并划分了平台的核心领域和通用子域， 最后结合成熟的体系结构风格对电信数据采集平台的整体设计提出解决方案。 本文分为五章，主要内容组织安排如下： 第l 章是绪论，主要介绍本文的研究背景及意义、研究状况、以及内容和组 织结构； 第2 章是领域驱动设计方法研究，阐述了领域驱动设计方法的思想，并介绍 3 东北大学硕士学位论文第1 章绪论 了设计过程中使用到的一系列模式和策略： 第3 章是数据采集平台的设计，包括建立数据采集领域模型，划分平台的通 用予域以及提出数据采集平台的整体解决方案； 第4 章是数据采集平台的实现，介绍了数据采集模型的相关实现，其中包括 数据采集协议的实现、数据加载的实现和模型的配置实现等； 第5 章是结论，总结了领域驱动设计在电信数据采集平台上的应用，并提出 其中的问题和不足，作为进一步研究的方向。 4 东北大学硕士学位论文 第2 章领域驱动设计方法 第2 章领域驱动设计方法 2 1 领域驱动设计相关知识 2 1 1 基本概念 领域驱动设计方法，是指由领域专家和软件设计人员共同建立领域模型，根 据领域模型指导软件设计和实现，同时软件设计人员在软件设计和开发的过程中 理解和学习业务，再与领域专家共同提炼、细化领域模型的迭代过程。领域驱动 设计方法还提供了一系列的策略和模式，来指导如何更好地建模和进行软件设计。 假如把“运用领域驱动设计方法进行软件设计”比作穿越一个原始森林的话， 那“与领域专家一起共同创建领域模型”的思想就应该是指南针，而“领域驱动 设计中一些策略和模式”应该是野外生存的工具。首先，指南针的重要性是无庸 置疑的，它是必不可少的，而其他工具要根据实际情况来使用，并不代表要走出 原始森林所有的工具都要使用到。此外，如果只有工具，没有指南针，就很可能 迷失在原始森林；如果只有指南针，没有工具，如果足够幸运，也是有可能走出 原始森林的。 2 1 2 过程描述 领域驱动设计的过程在某种程度上实际是一种“知识消化”的过程。高效的 领域建模人员就是知识的消化器，他们对大量信息中的相关部分进行探查，尝试 了一个又一个组织方式，寻找一种对复杂信息有意义的简单视图。 知识消化( k n o w l e d g ec r u n c h i n g ) 并不是一个孤立的活动，它是由开发团队 与领域专家共同合作，一起接收信息并对知识进行消化，使之成为有用的形式。 原始的资料一般来自于领域专家的意见、现有系统的用户、相关老式系统技术团 队的经验或同一领域中的另一项目口1 。 特别需要指出的是，在领域驱动设计中，知识消化并不是一种单向的学习， 即不仅仅需要软件设计人员学习一定的领域知识，同时也需要领域专家学习必需 的建模理论，并且在建模的过程中不断提炼自身的领域知识，以迎合软件设计中 概念的严格性。 软件的一般产生过程是：需求获取及分析、设计、编程、测试、部署。通常， 领域分析和软件设计是分裂的。分析人员从领域中收集基本概念，进行抽象，并 5 东北大学硕士学位论文第2 章领域驱动设计方法 创建业务模型；而软件设计是对业务模型的映射。以面向对象建模而言，虽然它 在建模上有着先天优势，但也仅仅是一种形式上的吻合，并不能代表软件设计本 身能真正抓住业务的实质。还有就是，软件设计人员自身的知识结构并不合理， 一般是以技术为主，即使拥有一定的领域知识，也是以前项目中零星的积累，缺 少对领域的全局把握。而且，这种方法的致命缺陷是完全没有反馈机制，知识只 是单向流动，没有进行交互式的积累。 另一种软件产生过程是迭代，开发人员让领域专家描述一项需要的功能然后 构造它，他们将结果展示给专家并询问下一步的工作。如果开发人员对该领域较 为熟悉，他们可以使得软件保持能够继续扩展的良好状态，但是如果程序员对领 域不感兴趣，他们只能知道应用程序应该做什么，却不了解其背后的原理。这样 的软件虽然能用，但不一定真正有用。这是因为他们未能有效的创建新知识，并 对它们进行抽象和积累。 这样的软件设计过程可能会引发两个弊端：一是以技术解决领域问题，二是 预判不准确，过度设计嘲。优秀的程序员会自然在软件设计初期开始进行抽象并 开发一个模型，但是当建模工作仅仅是在技术基础上进行，并没有领域专家的合 作时，这些概念是幼稚的，尤其是在复杂的领域中，很难获得软件设计的成功， 即使软件能够完成基本的工作，但由于缺乏领域的深刻认识，也会在以后软件的 扩展和维护过程中存在很大的困难【7 】。出现这些弊端的原因并非分析人员和软件 人员自身的问题，而是软件设计方法的不合理，所以领域驱动设计方法要求领域 专家和软件设计人员共同工作，建立领域模型，并将模型作为沟通的语言，使之 与程序保持同步更新。 在开发人员和领域专家一起讨论模型的过程中，领域模型不断精化，开发人 员不断地学习所必需的重要业务原理，而不是机械地产生新功能，领域专家也经 常提炼他们认为重要的领域知识，学习建模理论。因为程序员和分析人员的介入， 模型变得组织有序并且抽象合理，也为实现提供了很大的支持；又因为领域专家 的参与，模型反映出业务的深层知识，其抽象出来的都是真正的业务原则。 随着模型的完善，它逐渐成为项目中信息流的组织工具。模型关注的是需求 分析，它与编程和设计相互影响哪。在一个良性循环中，它能够加深团队成员( 领 域专家、软件设计人员和开发人员等) 对模型的理解，使得他们对模型了解得更 加清晰并对其进行进一步的改进。模型永远都不会是完美的，它们会不断地发展， 模型对领域来说必须是实用的，必须十分精确，使得应用程序易于实现和理解。 最后，需要强调的是领域驱动设计并不是画领域图，而是关于如何思考领域， 并如何组织软件以反映对领域更进一步理解的方法。 6 东北大学硕士学位论文第2 章领域驱动设计方法 2 2 分离领域 解决领域方面问题的模块通常只占整个系统的小部分，这与其重要性相比是 不成比例的。需要把领域对象和系统的其他功能相分离，才能避免将领域概念与 其他软件技术相关的概念混淆或者在庞大的系统中失去对领域的把握。 成熟的领域分离技术早已出现，为领域驱动设计建立了良好的基础，下面从 领域驱动的角度进行简单回顾。 2 2 1 分层结构 创建能够处理非常复杂任务的程序要求分离关注点，这样允许隔离地关注设 计中的不同部分。 对软件系统的分割有各种各样的方法，按照经验和惯例，软件行业确定了分 层架构，尤其是确定了一些公认的标准层。分层的隐喻得到了广泛的使用，绝大 多数开发人员都感觉到它很直观。分层的基本原则是：某一层中的所有元素只能 依赖同一层的其他元素，或者依赖其下层元素1 9 l 。 分层的意义在于每层都专门负责系统中的一个特定方面，这种基于专责的划 分，可以使各方面的设计更加具有内聚性，并且使得这些设计更加容易理解。当 然，如何选择层次是非常重要的。尽管有很多变体，但依据经验和惯例，大多数 成功的分层结构都会使用四种概念层的某些版本。下面对四种概念层进行介绍。 ( 1 ) 用户界面层( 表示层) ：负责向用户显示信息，并且解析用户命令。外 部执行者可以是人或者其他计算机系统。 ( 2 ) 应用层：定义软件可以完成的工作，并且指挥具有丰富含义的领域对象 来解决问题。这个层所负责的任务对业务影响深远，它不包括处理业务规则或知 识，只是给下一层中相互协作的领域对象协调任务、委托工作。在这个层次中不 反映业务情况的状态，但反映用户或程序的任务进度的状态。 ( 3 ) 领域层( 模型层) ：负责表示业务概念、业务状况的信息以及业务规则， 尽管保存这些内容的技术细节由基础结构层完成，反映业务状况的状态三在该层 中被控制和使用。这一层是业务软件的核心。 ( 4 ) 基础结构层：为上层提供通用的技术能力：应用的消息发送、领域持久 化，为用户界面绘制窗口等。通过架构框架，基础结构层可以支持这四层之间的 交互模式。 一些项目没有明显区分用户界面层和应用层，而有些项目则拥有多个基础结 构层，但是为了能够进行模型驱动设计，将领域层分离出来至关重要。将所有与 7 东北大学硕士学位论文第2 章领域驱动设计方法 领域模型相关的代码都集中在一层，并且将它与用户界面层、应用层和基础结构 层的代码分离。领域对象可以将重点放在表达领域模型上，不需要关心它们自己 的显示、存储和管理应用任务等内容，这样便于使模型发展得足够的丰富和清晰， 足以抓住本质的业务知识并实现它。 2 2 2 领域层 领域层是模型和所有与其直接相关的设计元素的显现，模型属于领域层。业 务逻辑的设计和实现构成了领域层。在一个模型驱动设计中，领域层的软件结构 反映出模型的概念。 当领域逻辑和系统的其他关注点混在一起时，要达到一致是很不现实的，所 以隔离领域实现是领域驱动设计的前提条件。 对每个企业应用，尽管能够区分出其中的主要的表现层、领域层和数据源层， 但是具体如何分离要取决于应用的复杂程度。从数据库中读取数据并把它显示在 w e b 页面上的简单脚本，可能全部在一个过程中，但仍然可以尽量保持三层架构 的风格，不过在这里可能只是把每个层的行为放在三个不同的子程序中。一旦系 统复杂一点，就可以将这三个层次的工作分解成不同的类。如果复杂度继续增加， 则把类分配到不同的包中。所以，是否分层取决于应用的复杂度0 i 。 但领域驱动设计适合领域和应用比较复杂的系统，隔离领域是领域驱动设计 的前提条件。当然，其他的开发风格也有他们的优势，但是必须在复杂性和灵活 性上做出考虑。缺乏领域设计的解耦，在某种情况下可能真是一种灾难。如果采 用了模型驱动设计来开发一个复杂的应用，就必须聘请某些必要的专家，并避免 采用智能u i 。 2 3 领域模型 2 3 1 领域模型功能 模型是处理信息过载负担的工具，它是知识的一种有选择的简化和有意识的 组织形式，一个合适的模型能够了解信息的含义并聚焦于问题的本身。领域模型 是领域驱动设计的核心概念，下面介绍其重要性。 ( 1 ) 模型与设计核心相互塑型。 正是模型与实现之间密切的联系使得模型与现实相关，并且保证对于模型的 讨论分析能够应用于最终产品可运行程序。这种模型与实现之间的绑定对于 一8 东北大学硕士学位论文 第2 章领域驱动设计方法 软件的维护和继续开发也很有帮助，因为可以根据模型来理解代码。 领域驱动设计抛弃了分裂分析模型与设计软件的方法，而是寻找一个单独的 模型来满足这两方面的要求。将纯粹的技术问题放到一边，设计中的每个对象都 担当模型中描述概念上的一个角色。这就需要对选择的模型有更多的要求，因为 它必须满足两个完全不同的目标。 对领域进行抽象有很多方式，要解决一个应用问题通常也有很多种设计。这 使得绑定模型与设计成为可能。这种绑定不能够以削弱分析、基于技术性考虑为 代价；也不能够接受拙劣的设计，虽然这些设计反映了领域的概念但却舍弃了软 件设计的原则。这种绑定方式要求一个模型在分析与设计方面都取得良好的效果。 当一个模型对于实现不实用时，必须寻找一个新的模型；当模型没有忠实地表达 领域的关键概念时，也要重新寻找一个新的模型。这样，建模与设计过程就成为 了单个迭代循环。 ( 2 ) 模型是所有团队成员所使用的语言核心。 由于模型与实现是相互绑定的，因此开发人员可以用这种语言来讨论程序， 他们能够在没有翻译的条件下与领域专家交流，又由于这种语言是基于模型的， 自然语言能力也能够用来细化模型本身。 当一个项目的语言存在断层时，会面临一系列的问题：领域专家使用自己的 行话，而技术团队成员却按照设计的思路调整和使用自己的语言去讨论领域。每 次讨论时所使用的术语与嵌入到代码中术语是分裂的，甚至同一个人，在编写文 挡或代码时，也会使用跟交流讨论时完全不同的语言，这会导致对于领域的某些 深入描述只是短时间内存在，却无法反映到代码或文挡中。这种语言转换减弱了 交流的效果，使得知识积累也不尽如人意。 在领域驱动设计中，要求领域模型成为项目成员( 包含领域专家) 所使用的 通用语言的核心。模型是建立在项目成员头脑中的一组概念，它使用术语及关系 来反映领域的内涵。这些术语和相互的关系规定了适合于领域的语言语义，该语 义对于技术开发而言是足够精确的，同时也是将模型贯穿到开发活动中，并将模 型与代码进行绑定的关键。 ( 3 ) 模型用来提炼知识【1 1 】。 模型是团队在组织领域知识和辨别最感兴趣的原理时一致同意的方式，在选 择术语、分解概念并将它们相互联系起来时，模型能够反映出是怎样考虑领域问 题的。开发人员与领域专家将信息放置于模型这种形式中，公用的语言可以使他 们的合作更加高效。 此外，领域驱动设计方法的建模范式主要是面向对象设计。这种优势来自几 o 东北大学硕士学位论文第2 章领域驱动设计方法 个方面：有些是对象自身的优势，有些是开发环境的原因，还有些是因为被广泛 使用的原因。 开发团队选择使用对象范式的许多原因并不是出于技术上的考虑，甚至也不 是出于对象本身性质的考虑。但是对象建模正在简单和复杂之间创造一种有效的 平衡。 如果建模范式太深奥，就不会有足够的开发人员能够掌握它，就不会得到正 确的应用。如果团队中的非技术人员如果连范式的入门知识都不能掌握，他们就 不可能理解模型，模型中的通用语言将会失去使用的机会。面向对象设计的基本 原理在绝大多数人看来都很自然，容易理解。即使一些开发人员遗漏了建模的一 些细节，甚至连非技术人员也能够理解对象模型的图型。 当然，领域模型并不一定都是对象模型。例如，系统中某一部分，需要复杂 的数学计算，可以使用一个适合表示数学计算的范式建立模型，然后在系统中采 用合适的方式将其隔离起来1 1 2 1 。 2 3 2 领域模型描述 首先将从如何设计和组织关联开始讨论，对象间的关联非常容易得到，也可 以很容易表示出来，但要实现它们并不容易。 然后，转向对象本身，将对用来表述模型的元素进行划分。共有三种模式， 分别是：实体( e n t i t y ) 、值对象( v a l u e0 b j e c t ) 和服务( s e r v i c e ) 。从表面上看， 把捕获的领域关键概念对象化是非常容易的，但实际上，要捕捉隐藏在表象下的 概念却是很大的挑战，因为需要对模型元素的意义进行明确的区分，并把它应用 到设计实践当中，来创建一些特定类型的对象。 ( 1 ) 关联 在现实世界中，存在着大量的关联，由于建模与实现之间的相互影响使得对 象之间的关联变得特别难以处理。在处理关联时，要尽可能的对关联进行约束。 一个双向关联意味着，只有两个对象同时放在一起时才能被理解。如果应用并不 要求在两个对象问进行双向交互，那么指定一个导航方向可以降低对象的相互依 赖性，并且使设计得到简化。 对于关联的一些规则有：指定一个导航方向；通过加入限定符( q u a l i f i e r ) 来 有效地减少关联的多重性( m u l t i p l i c i t y ) ；清除不必要的关联等等p 1 。 充分地理解领域，仔细地提炼并约束模型中的关联，可以引导沿着模型驱动 设计的方向前进。 1 0 东北大学硕士擘位论文第2 章领域驱动设计方法 ( 2 ) 实体 一个对象所代表的事物是一个具有连续性和标识的概念( 可以跟踪该事物经 历的不同状态，甚至可以让该事物跨越不同的实现) ，还只是一个描述事物的某种 状态的属性，这就是实体和值对象最本质的区别吲。明确选用两种模式中的一种 来定义对象，可以使对象的意义更清晰，并可以创建一个健壮的设计。 实体不是由它们的属性来定义，而是通过一系列连续性( c o n t i n u i t y ) 和标识 ( i d e n t i t y ) 来从根本上定义的。在软件系统中，只要一个对象在生命周期中能够 保持连续性，并且独立于它的属性，那它就是一个实体。要特别注意的是，对象 的标识是业务领域的概念，并非技术实现上的概念。 在对实体建模中，关注的重点不是它们全部的属性和行为，应该只留下那些 固有的特征，特别是那些用来惟一标识对象，以及经常用来查找和匹配对象的特 征。并且只加入核心概念所涉及到的行为，以及行为所需要的属性。此外，想办 法将属性和行为转移到与核心实体相联系的其他对象中去，这些对象可能是其他 实体，也可能是值对象。除要解决标识问题之外，实体往往通过协调它拥有的 对象之间的操作完成自己的职责。下面用一个例子形象地介绍如何对实体进行建 模，如图2 1 所示。 图2 1 实体建模图 f i g 2 1e s t a b l i s ht h ee m i t ym o d e l c u s t o m e r l d 是c u s t o m e r 实体的标识，也是惟一的标识。但是电话号码和地址 都经常被用来查找和匹配客户。名字虽然不能作为人的标识，但也经常作为确定 人的属性之一。所以，关于c u s t o m e r 重构如图2 1 所示，但重构标准并不是惟一 的，这取决于在实际项目中，领域中的对象是怎样匹配和区分的。 ( 3 ) 值对象 东北大学硕士学位论文 第2 章领域驱动设计方法 如果只关心模型中一个元素的属性，那么就把这个元素划分为值对象。用它 来描述它所要表达的那些属性的意义，并提供相应的功能。把值对象看成是不可 变的，不要给它任何标识，这样可以避免实体的维护工作，降低设计的复杂性， 如图2 2 所示。 图2 2 值对象建模图 f i g 2 2e s t a b l i s ht h ev a l u eo b j e c tm o d e l 组成值对的属性应该形成一个总体的概念，例如，街道、城市和邮政编码不 应该从c u s t o m e r 类中分离出去，但却应该作为个整体存在，这样能够使 c u s t o m e r 得到简化，同时也使得地址成为一个更加紧凑的对象，便于复用。 ( 4 ) 服务 领域中存在很多方面，有时用行为或操作来描述它们会比用对象来描述更加 清晰。尽管与面向对象建模理念稍有抵触，但这些最好用服务来描述，而不是将 操作的职责强加到某些实体或值对象中嘲。在软件的技术层面存在很多服务，服 务也同样出现在领域中，它们用于对软件必须完成的一些活动进行建模，但是与 状态无关。 服务，它强调与其他对象的联系。与实体和值对象不同，服务完全是根据能 够为客户做什么而定义的，即服务用来为客户请求提供服务。服务往往代表一种 行为，而不是一个实体，是一个动词而不是一个名词。服务可以有一个抽象的、 有意图的定义，这与对象的定义有所不同。服务应该还有一个定义好的职责，它 的职责和接口被定义为领域模型的一部分。操作名应该来自通用语言，如果通用 语言中还没有这个操作名，则应该把它添加进去。调用的参数和返回的结果应该 是领域对象。 一个优秀的服务具备三种特征：与领域概念相关的操作不是实体和值对象中 固有的部分、接口根据领域模型中的其他元素来定义和操作是无状态的。 这里的无状态是指任何一个客户都可以使用服务的所有实例，而不管这个实 例的来源。服务的执行将使用全局可访问的信息，甚至改变这些信息，但是服务 1 2 东北大学硕士学位论文第2 章领域驱动设计方法 不保留影响自己行为的状态，而绝大多数领域对象是要保留这些状态的。 所以，当领域中一个重要进程或转换操作不是实体和值对象的职责时，把操 作作为一种独立的接口加入模型，并声明为服务。根据模型中使用的语言来定义 接口，保证操作名是通用语言的一部分。使这个服务变为无状态的。 2 3 3 领域对象生命周期 每个对象都有它的生命周期，一个对象在创建以后，可能要经历各种不同的 状态，并最终消亡( 被存档或者删除) ，如图2 3 所示。 i 匠( 三j e 删磉归愦 丫_ 、 适s 一删除弋数据库或文件表示) 当然，许多对象都是简单的临时对象，只是调用其构造函数把它们创建出来， 在某种计算中是使用它们，然后扔到垃圾收集器中。但是，其他对象的生命周期 更长，在生命期中有时并不驻留内存，而且它们与其他对象存在着复杂的依赖关 系，在经历状态变迁时还要满足一些不变量的约束条件。如何管理这些对象是一 个挑战，处理不好就很容易使工作偏离模型驱动设计的方向。 如何处理好领域对象的生命周期问题，挑战有两类：在生命周期中如何维护 对象的完整性和如何避免模型由于管理生命周期的复杂性而陷入困境。 将使用三个模式来处理这些挑战：建立聚合的模型，并把工厂和仓储加入到 设计当中，可以对模型对象进行系统地操纵，同时使得这些对象的生命周期成为 一个个意义明确的单元。聚合划定一个范围，把一些相关的概念聚合在一起，在 这个范围内中无论对象处于生命周期的哪个阶段，都应该保持不变性，工厂和仓 储对聚合进行操作，将特定生命周期变迁的复杂性封装起来。虽然工厂和仓储本 身并不是从领域中产生的，但它们在领域设计中的作用不容忽视。这些构造提供 1 3 东北大学硕士学位论文第2 章领域驱动设计方法 了访问和控制模型对象的方法，完善了模型驱动设计。 ( 1 ) 聚合 聚合( a g g r e g a t e ) ，通过定义清晰的所有权和边界来使模型变得更紧凑，避 免出现盘根错节的对象关系网。这个模式对于在生命周期的各个阶段中维护完整 性非常关键【”。 一个聚合是一簇相关联的对象，出于数据变化的目的，将这些对象视为个 单元。每个聚合都有一个根( r o o t ) 和一个边界。边界定义了聚合中包含什么； 根是包含在聚合中的单个特定的实体。根是聚合中惟一允许被外部对象引用的元 素，但是在聚合的边界内，对象之间可以互相引用。根之外的实体具有本地标识， 但是它们仅仅在聚合内部才需要区分其标识，因为根实体上下文以外的对象不会 看到它们。 为了将概念上的聚合转换为实现，需要在所有的事务中应用一系列的规则。 根实体具有全局标识，并最终负责对不变量的检查( 不变量是指无论何时数 据发生变化都必须满足的一致性规则) ，当在聚合边界内发生任何对象修改后被提 交时，整个聚合的所有不变量必须都被满足。而且，根实体具有全局标识，边界 之内的实体具有本地标识，这些标识仅在聚合内部是惟一的。 聚合边界以外的任何对象除了可以引用根实体，不能持有任何对其内部对象 的引用。根实体可以把其内部实体的引用传递给其他对象，但是它们只能临时使 用这种引用，而不能持有这种引用。根还可以复制一个值对象的副本传给另一个 对象，它并不关心这个副本会发生什么变化，因为那只是一个值，而且与聚合已 经不再有任何关系了。 ( 2 ) 工厂 在生命周期的开始部分，用工厂( f a c t o r y ) 来创建和重组复杂的对象和聚合， 并保持对其内部结构的良好封装l 。 当创建一个对象或整个聚合的逻辑变得非常复杂，或者过多地暴露了内部结 构时，工厂提供了封装。生命周期管理具有复杂的职责，因此如果让一个复杂对 象来负责自身的创建工作，就会由于职责过载而产生问题。 组装一个复杂的复合对象的工作，与该对象被组装成功后所执行的任何其他 工作，最好是分开的。但是，如果把组装的职责转移给其他对此感兴趣的对象， 如应用中的客户对象，那就会使问题变得更加糟糕。客户知道需要让哪些领域对 象来执行必须的计算，从而完成自己的工作。如果希望让客户程序来组装其所需 的领域对象，那它就必须知道一些有关对象内部结构的事情。为了保证领域对象 中各个部分之间的关系满足所有不变量，客户程序又必须知道该对象上的某些规 1 4 东北大学硕士学位论文第2 章领域驱动设计方法 则，即使是调用构造函数也会使客户与它正在创建的具体类关联起来。对领域对 象的实现所做的所有修改都需要客户做出相应修改，导致重构更加困难。 让客户来负责创建对象的工作，使问题不必要的复杂化了，也模糊了客户程 序的职责，这样也破坏了被创建的领域对象和聚合的封装。更糟糕的是，如果客 户是应用层的一部分，那就导致这个职责完全从领域层泄露到了应用层。这种应 用与实现细节的紧密关联丧失了领域层抽象的大部分优点，而进一步的修改所需 的代价则更加昂贵。 复杂对象的创建工作是一种领域层的职责，然而创建工作并不属于表达模型 的对象。因此，将创建复杂对象或聚合的实例的职责分离到一个单独的对象中来， 这个对象本身可能在领域模型中没有职责，但仍然是领域设计的一部分，它提供 了一个将所有复杂的组装封装起来的接口，这样客户就无需引用它要实例化的对 象的具体类，用工厂把聚合作为一个整体创建出来，并保证其不变量得到满足。 一般而言，创建工厂的目的是为了把待创建对象的细节隐藏起来，并在希望 进行控制的地方使用工厂，这些决定通常是围绕聚合来考虑的。例如，如果需要 向一个已有的聚合中加入元素，那么可以在聚合根中创建一个工厂方法。这可以 把聚合的内部实现向所有外部客户隐藏起来，同时由根负责保证聚合在加入元素 之后的完整性。 ( 3 ) 仓储 仓储( r e p o s i t o r y ) 提供了领域对象的查询访问，一些实体或者值对象在生命 周期范围内是需要存储在数据库中的，在领域驱动设计中，模型并不对所有存储 在数据库中的对象提供访问接口，而是把这种访问接口尽可能的减少，一是为了 隔绝领域对象与数据库的直接联系，二是可以增强模型的表现力，让领域专家能 更好地理解模型。 仓储用于处理生命周期的中间和结束部分，提供了查询和提取持久对象的方 法，同时把与生命周期管理有关的复杂基础设施封装起来】。 领域驱动设计的目标是通过聚焦领域的模型来设计更好的软件。但是，当开 发人员构造一个s q l 查询，把它传给基础结构层的查询服务，得到一个表记录的 结果集，从中取出必需的信息，然后把那些信息传给构造函数或者工厂的时候， 模型的焦点已经丢失了，很自然就会把对象想象为查询所得数据的容器，而整个 设计就偏向数据处理风格了。即使采用一些技术，是查询结果和对象之间可以方 便的转换，但问题依然存在：客户正在和技术打交道，而不是模型概念。更糟糕 的是，由于客户代码能够直接使用数据库，开发人员会忍不住绕过一些模型特性， 例如聚合，甚至对象的封装，取而代之的是直接把他们需要的数据取出来进行操 1 5 东北大学硕士学位论文 第2 章领域驱动设计方法 作。 仓储提供获取对象引用的大致原则。首先，不用关注临时对象，因为临时对 象( 通常是值对象) 的生命周期很短，它们在客户操作中被创建出来，用完之后 就被丢弃了。另外，也不需要为那些可以方便地通过导航访问的对象，提供查询 方法，即聚合的任何内部对象只能通过根来导航，其他的访问途径都是禁止的。 所以，通常为一个聚合根提供全局查询的接口。 仓储具有许多优点，包括：为客户提供了一个简单的模型，来获取持久对象 并管理其生命周期；把应用和领域设计从持久技术、多种数据库策略或甚至多种 数据来源解耦出来；传达了对象访问的设计决策：可以很容易被替换为其他实现， 以便在测试中使用。 2 3 4 简单模型和深层模型 对象分析的传统方法包括从需求文档中界定出名词和动词，然后把它们作为 最初的对象和方法3 l 。许多人认为这种方法将问题过于简化，然而事实上，在构 造最初的模型的时候，通常都是基于一些浅薄的认识，因此最初的模型往往是非 常幼稚和浅薄的，这时的模型称为简单模型。 但随着对领域的逐步认识，领域模型不断的重构、迭代，模型会逐渐转变为 深层模型。 深层模型( d e e pm o d e l ) 能够清晰地表达出领域专家所考虑的主要问题，以 及与这些问题关系最为紧密的知识，同时它又剥离了领域中的一些表面现象。一 个深层模型通常包含抽象元素，但是它也可以包含具体元素，以便能够直接切入 到问题的核心。 当模型确实与领域非常贴切时，它就会获得功能强大、简单易懂的特点。这 种模型几乎都具有一个共同特点，那就是它们都使用业务专家喜欢使用的、简单 的语言。 2 3 5 领域模型小结 在领域驱动设计中，模型一般用非正式u m l 图和一些辅助性说明来形象地 表示。 需要明确地是，领域模型并不是某种特殊的图，而是图所要表达出的思想， 它并不是领域专家头脑中的知识，而是对相关知识进行严格