【毕业学位论文】（Word原稿）基于.Net Web的Music Store的领域驱动设计与实现-软件工程

硕士学位论文 （专业学位） 姓 名： 学 号： 所在院系：软件学院 职业类别：工程硕士 专业领域：软件工程 指导教师： 副指导教师： 二一三年 九 月 基于 领域驱动设计与实现 A in 2010 F N 2013 基于 领域驱动设计与实现 同济大学 学位论文版权使用授权书 本人完全了解同济大学关于收集、保存、使用学位论文的规定，同意如下各项内容：按照学校要求提交学位论文的印刷本和电子版本；学校有权保存学位论文的印刷本和电子版，并采用影印、缩印、扫描、数字化或其它手段保存论文；学校有权提供目录检索以及提供本学位论文全文或者部分的阅览服务；学校有权按有关规定向国家有关部门或者机构送交论文的复印件和电子版；在不以赢利为目的的前提下，学校可以适当复制论文的部分或全部内容用于学术活动。 学位论文作者签名： 年 月 日 同济大学学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师指导下，进行研究工作所取得的成果。除文中已经注明引用的内容外，本学位论文的研究成果不包含任何他人创作的、已公开发表或者没有公开发表的作品的内容。对本论文所涉及的研究工作做出贡献的其他个人和集体，均已在文中以明确方式标明。本学位论文原创性声明的法律责任由本人承担。 学位论文作者签名： 年 月 日 同济大学 硕士学位论文 摘要 I 摘要 软件系统面向对象的设计思想可谓历史悠久， 20 世纪 70 年代的 到今天我们依然将这门语言视为面向对象语言的基础 , 但是面向对象语言并不是 万能的 ，如果开发人员认为使用面向对象语言写出来的程度本身就是面向对象的，那就大错特错了，实际开发中，大量的业务逻辑堆积在一个巨型类中的例子屡见不鲜，代码的复用性和扩展性无法得到保证。为了解决这样的问题，领域驱动设计提出了清晰的分层架构和领域对象的概念，让面向对象的分析和设计进入了一个新的阶段，对企业级软件开发起到了巨大的推动作用 。 从领先的软件设计人员开始将领域驱动建模以及设计是为关键性课题到现在也有多年的历史了。然而，目前国内却也几乎没有相关的文献来告诉大家应该做什么和如何做，尽管领域驱动建模和设计并没有被明确化，然而在对象领域中出现了一种潜在的哲学体系，它就是我们所说的领域驱动设计 ( 本文 主要介绍了领域驱动设计的基本概念、要素和特点，并 尝试 通过设计一个 一个精简的电子 唱片商店 系统来展示 领域驱动设计开发方法 的设计过程那个和理念。首先，从一步步构建 领域通用语言 （ 开始 ， 然后建立具体的领域模型， 并且通过分析和解决领域模型中的关键性问题精细化领域模型，通过使用经典 架来实现该系统。根据框架的需要，先是搭建了领域核心模型，最后划分了领域服务，并且实践了 从测试驱动 (行为驱动 (发 来验证 领域模型 的业务逻辑 ,在文中，会使用到 依赖注入等概念 。 整个设计都充分 突出 和体现了 领域驱动设计开发方法的一个完整流程和设计理念。 关键词 ： I he a in 970 s, be as we as is It is in is In of of in s be In to a of a it a in t a as a is to to do to is is a In I am to an of to at to by a to of in it in in to we in on I VC in I to of in 硕士学位论文 目录 录 第 1章 引言 . 1 题背景与意 义 . 1 内外发展现状 . 1 课题的主要研究内容 . 2 文的组织结构 . 2 第 2章 相关理论介绍 . 4 . 4 域驱动设计概述 . 4 . 5 . 6 . 7 . 8 . 8 . 9 . 10 . 11 . 11 架 . 12 （ . 20 现层实现 . 22 术 . 26 续集成技术概述 . 26 术的实现 . 28 章小结 . 29 第 3章 构建领域模型 . 30 何构建通用语言 . 30 话场景模拟构建通用语言 . 30 勒模型 . 32 化领域模型问题 . 34 . 34 个地分析领域中的问题点 . 35 建系统权限管理模型 . 42 同济大学 硕士学位论文 目录 实现 . 42 . 44 . 45 I（用户界面）原型 . 45 . 46 . 46 . 46 . 54 章小结 . 54 第 4章 实现领域核心模型 . 56 统架构回顾 . 56 . 56 . 58 分领域服务 . 61 存服务详细设计与实现 . 61 单管理服务详细设计与实现 . 64 . 67 物车服务设计与实现 . 68 告信息服务 . 70 章小结 . 70 第 5章 应用 . 71 践 . 71 . 72 过 华领域模型中的 . 73 践 . 79 建 试环境 . 80 用 试服务 . 81 章小结 . 85 第 6章 基础设施层和表现层的实现 . 86 久化架构的需求 . 86 用 . 86 实现 . 91 他公共实用方法的实现 . 94 . 94 I. 96 第 7章 总结与展望 . 102 结 . 102 望 . 103 同济大学 硕士学位论文 目录 V 致谢 . 104 参考文献 . 105 个人简历、在读期间发表的学术论文与研究成果 . 106 第 1章 引言 1 第 1 章 引言 题 背景与 意义 众所周知， 应用软件是为满足用户不同领域、不同问题的应用需求而提供的 ，也就是说，软件本身的价值所在主要是实现领域逻辑，帮助用户处理领域问题的。然而，在企业级应用 的开发工作中， 开发人员对领域业务的认识，和对领域知识的获得，往往比不上领域专家。开发人员最熟悉的是技术，这就导致最后 在设计软件的时候， 开发人员 趋向于一种以技术为先导的过程。因为软件的领域需求传递到开发团队 后，开发人员依据需求上的描述创造出最有可能的假想。在瀑布开发模型中，我们需不停校对，复核需求分析文档，尽最大的努力将一份完美的文档移交给开发人员，然后开发人员根据文档，以他们的思维设计出一套能够运行的软件；每当需求发生变更时，开发人员都会十分头疼和烦恼，难免就可以听到很多开发人员的怨气声。 领域驱动的设计是一种截然不同的设计方法学，它知道需求是永远不是一成不变的，需求是一个活的文档，它把软件系统当作业务过程的一个影射，是 使能动，而不是驱动 1。领域驱动设计是要你深入到业务过程中，了解业务术语和实践方法。技术方面的事被放在了第二位，只是最终的一种手段而已。 领域驱动设计是敏捷方法的终极表达 ,它是用来处理不断变化和发展的需求。 正如任何一个从未涉足软件项目的人都知道一个项目的需求从开始到结束保持一成不变是极其罕见的，绝大多数情况是它会随着业务的增长和变化而变化2。 内外发展现状 在传统的开发工作中，开发人员趋向于一种以技术为先导的过程，需求从业务方传递到开发团队，然后，开发人员依据需求上的描述创造出最有可能的假想 。在瀑布开发模型中，我们需不停校对，复核需求分析文档，尽最大的努力将一份完美的文档移交给开发人员，然后开发人员根据文档，以他们的思维设计出一套能够运行的软件；每当需求发生变更时，开发人员都会十分头疼和烦恼，难免就可以听到很多开发人员的怨气声。 然而，领域驱动的设计是一种截然不同的设计方法学，它知道需求是永远不是一成不变的，需求是一个活的文档，它把软件系统当作业务过程的一个影射，同济大学 硕士学位论文 基于 设计与实现 2 是使能动，而不是驱动。领域驱动设计是要你深入到业务过程中，了解业务术语和实践方法。技术方面的事被放在了第二位，只是最终的一种手段而已 。 世界著名软件建模专家 他在全球各地宣讲领域驱动设计的思想，开设课程、参加会议、接受专访，拥有大批的追随者。从 20世纪 80年代开始，他就以设计师和程序员的双重身份参与过许多大型面向对象系统的设计和开发，涉及各种复杂的业务和技术领域 ，目前市面上也出现了众多的关于 课题的主要研究内容 这个课题的业务内容不会过于复杂，但希望能够通过一个相对经典的设计，呈现出一个完整的以 域设计驱动 )方法开发和实现过程；以往我在学习微软的开发技术的过程中 ，也发现微软也经常会以一些实际的案例来完整的展现他们推广的技术如何在现实的开发过程中得到应用的，譬如，以往的通过 过 展现 也希望这个设计可以成为一个“麻雀虽小，五脏俱全”的设计。 名思义，就是一个音乐商店，商家可以上架商品，发布商讯，客户可以登录到商店的网站上购买相关的产品，业务内容可以说是三言两语即可描述清楚的。我想结合 域设计驱动 )、 试设计驱动 )、 为设计驱动）的 设计原则搭建和实现它，大多情况下，我们使用的还是；软件最终的目的是实现某些业务和服务，软件的最终价值就是提供人们所需要的服务，科学的开发方法就是应该直接从业务模型上驱动整个开发 3。 希望能够结合理论，将科学的方法论应用到一个实际的项目当中，在这个项目里使用到的方法论，必定是可以举一反三的 ,该设计 所使用到具体技术主要有： (一 ) 目的代码的总体设计框架 (二 ) 目的 架，数据的持久化框架。 (三 ) 了实现 用 的 架。 (四 ) 了做情景测试使用的行为测试驱动框架 . (五 ) 赖注入容器 (六 ) 目的展现层框架 文的组织结构 本文共分为 七 个章节： 第 1章 引言 3 第一章，引言。说明了 项目的 研究意义、国内外发展现状，以及本课题的主要研究内容 。 第二章， 相关理论 介绍 。介绍了课题研究的技术支持和理论支持，其中 涉及到的主要是 计所涉及的所有理论基础和本文所使用到的相关技术和工具，本章是所有后面章节的一个理论基础 。 第三章， 构建领域模型。该设 计与传统的设计方法有所不同，在第三章我们通过对话的模式构建出了领域通用语言，并且在领域通用语言的基础之上再构建了领域模型，通过深化领域的分析，提出了领域必须解决的一些问题，并提出了解决方案。 第四章， 实现领域核心 模型 。 该设计是基于 构设计的， 构里最基础的就是领域的核心模型，在第四章节中，主要完成了核心模型的实现和搭建 ，划分了所有的领域服务。 第五章， 应用 通过对编写 试用例， 象接口的方式测试了第四章节中的领域服务，并且以实际案例使用 示了 第六章， 基础设施层和表现层。实现了 构中的基础设施层和表现层，主要使用微软的 现 架，以及实现了 式。最后，在章节的最后，描述了展现层的大体实现，主要使用 架构。最后还是具体展示了依赖注入（ 具体实现。 第七章，总结了自己对 及软件工程开发学的一些理解，并提出了展望。同济大学 硕士学位论文 基于 设计与实现 4 第 2 章 相关 理论 介绍 域驱动设计概述 软 件开发通常被应用到真实世界中已经存在的自 动化流程，或者给真实的业务问题提供解决方案，即要自动化的业务流程或者可以用软件解的现实问题 4。从一开始，我们就必需明白软件脱胎于领域，并跟领域密切相关。软件是由代码最终构成的。也许我们被代码所诱惑，在它上面花费了太多的时间，将软件看作是简单的对象或者方法。 任何一个软件都会与用户的活动或者业务相关。用户在其中使用程序的主要环境成为软件的 领域 ，英文通常翻译为“ 大多数的领域会涉及到物质世界，譬如企业资金流管理软件的领域就是货币和金融相关的业务，领域的概念通常都和用户的需求紧密相关，通常和计算机 世界的概念很少有直接关系。要开发构建一套对于用户有价值的软件，开发团队必须要 从 用户关心的这些业务活动 中提取出业务知识的主体。而这所要求的知识广度可能是令人生畏的，信息的容量和复杂度也是令人难于想象的。而 模型 正在处理这种过载负担的工具。 模型 是知识的一种有选择的简化和有意识的组织形式。一个合适的模型能够了解信息的含义并聚焦于问题的本省 5。 领域模型的最终产物并不是设计出某种特殊的图，譬如我们熟知的 所关心的是这个图要表达意思。它不仅仅是某个领域专家头脑中的知识，而是对相关知识进行严格的组织与选择性 地一种抽象。领域模型也并不是尽可能去制造出一个逼真的模型，即使在我们真实的世界里的事物领域中，我们的模型也不过是一个仿真的创造物，譬如我们 在购房中心 能够看到 房子的模型，模型的设计人员会想方设法凸显出整个房子的亮点，以一种特殊的方式展现出来。领域建模人员也应该如此，在设计的过程中要紧紧抓住业务重点，并将其充分体现在构建的模型中。最后，这个模型图可以表达的东西，通过代码以及语言也是可以表述清楚的。 领域驱动设计中模型的作用归纳起来有以下三个用途： (一 ) 模型与设计核心的相互塑型。正是模型与实现之间的紧密联系使得模型与现 实世界相关并且保证模型的讨论分析能够产生最终的软件产品，即一个可运行的程序。 第 2章 相关 理论 介绍 5 (二 ) 模型是所有开发人员所使用的语言的核心。由于模型和实现是相互绑定的。因此开发人员可以用这种语言来讨论程序。他们能够在没有翻译的条件下和领域专家进行交流。 (三 ) 模型用来提炼知识。模型是团队在组织领域知识和辨别最感兴趣的原理是一致同意的方式。在我们选择的术语、分解概念并将它们相互联系起来时，模型能够反映出我们是怎么样考虑领域问题的。开发人员与领域专家将信息放置于模型这种形式中。 如果我们想要进一步细化模型设计，我们将需要阐述 计过程中 的一些构成元素：通用语言、分层、实体、值对象、服务、模块 、聚合、工厂和资源库。在下面的段落中，本文将一一进行必要的阐述。 用语言 通过前面段落的介绍，模型的构造不是凭空想象的出来的，它的构建需要开发人员和领域专家一起协同合作。 但是 ，他们之间的协作经常会 由于一些基础交流的障碍而存在难点。开发人员满脑子都是类、方法、算法、模式，总是想将实际生活中的概念程序工件做对应。 为克服这种交流方式的不同，在建立模型时，我们必须通过沟通来交换对模型和模型中涉及到的元素的想法，应该如何连接它们，哪些是有关的，哪些不 是？在这种层次上的交流对一个成功的项目而言是极为重要的。如果一个人说了什么事情，其他的人不能理解，或者更糟的是错误理解成其他事情，又有什么机会来保证项目成功呢？ 在设计过程中，我们倾向于使用自己的方言，但是没有一种方言能成为一种通用的语言，因为它们都不能满足所有的需要。在讨论模型和定义模型时，我们确实需要讲同一种语言。那么是哪种语言呢？开发人员的语言？领域专家的语言？介乎两者之间的语言？领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足领域的共同点，它很适合作为这种通用语言的构造基础。 使用模型作为语言的核心骨架。要求团队在进行所有的交流是都使用一致的语言，在代码中也是这样。在共享知识和推敲模型时，团队会使用演讲、文字和图形。这儿需要确保团队使用的语言在所有的交流形式中看上去都是一致的。因为这个原因，这种语言被称为“ 通用语言（ ” 6。 通用语言连接起设计中的所有的部分，建立了设计团队良好工作的前提。可能会花费数周乃至数月的时间才能让一个大规模项目的设计成型。团队成员会发现一些初始的概念是不正确的或者不合适宜，或者发现一些需要考虑并放进总体设计中的新 的设计元素。没有了通用语言，所有的这一切都是不可能的。 通过尝试反映其他可选模型的其他的表述方式，可以消除这个难点。然后重构代码、重同济大学 硕士学位论文 基于 设计与实现 6 命名类、方法和模型以适应新的模型。使用我们能够正常理解的普通词汇，化解交谈所使用术语之间的混乱。构建一个类似这样的语言会得到一个清晰的结果：模型和语言相互密切关联。一个对语言的变更会变成对模型的变更。领域专家会反对用那些很笨拙的或者不适当的字眼或者结构来传达对领域的理解。如果领域专家不能理解模型或者语言中的某种内容，那么就如同是说这种内容存在某种错误。从另一方面讲，开发人员应该留 意那些与他们试图呈现在设计中的内容存在二义性或者不一致的部分。 层 当人们讨论分层的时候，总是很难区分 区别，这两个词汇经常被用作同义词， 多地被认为是物理上的分离 7错误 !未找到引用源。 。我们强调是无需把不同的层次放在不同计算机上运行。独立出来的逻辑层，既可以运行在台式计算机，也可以运行在数据库服务器上。 当我们创建一个软件应用时，这个应用的很大一部分是不能直接跟领域关联的，但它们是基础设施的一部分或者是为软件服务 的。最好能让应用中的领域部分尽可能少地和其他的部分掺杂在一起，因为一个典型的应用包含了很多和数据库访问，文件或网络访问以及用户界面等相关的代码。在一个面向对象的程序中，用户界面、数据库以及其他支持性代码经常被直接写到业务对象中。附加的业务逻辑被嵌入到 件和数据库脚本的行为中。之所以这样做的某些原因是这样可以很容易地让事情快速工作起来。但是，当领域相关的代码被混入到其他层时，要阅读和思考它也变得极其困难。表面看上去是对 修改，却变成了对业务逻辑的修改。对业务规则的变更可能需要谨慎跟踪用户界面层 代码、数据库代码以及其他程序元素。实现粘连在了一起，模型驱动对象于是变得不再可行。也很难使用自动化测试。对于每个活动中涉及到的技术和逻辑，程序必须保持简单，否则就会变得很难理解。 因此， 因此，将一个复杂的程序切分成层。开发每一个层中内聚的设计，让每个层仅依赖于它底下的那层。遵照标准的架构模式以提供层的低耦合。将领域模型相关的代码集中到一个层中，把它从用户界面、应用和基础设施代码中分隔开来。释放领域对象的显示自己、 保存自己、管理应用任务等职责，让它专注于展现领域模型。这会让一个模型进一步富含知识，更清晰地捕获 基础的业务知识，让它们正常工作。 领域驱动的经典分层主要分为： 4 个层：表现层、应用层、领域层、基础设施层。 第 2章 相关 理论 介绍 7 表 域驱动设计的经典分层 用户界面 /展现层 负责向用户展现信息以及解释用户命令。 应用层 很薄的一层，用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态，但它保有应用任务的进度状态。 领域层 本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态，对业务对象和它们状态的持久化被委托给了基础设施层。 基础设施层 本层作为其他层的支撑库存在。它提供了层间的通 信，实现对业务对象的持久化，包含对用户界面层的支撑库等作用。 和值对象 在领域中，可以抽象出拥有标识符的对象，标示符在经历了各种状态之后仍然能够保持不变，我们把这样的对象称为实体 ， 所以实体的特性就是拥有 标识 符8。 有很多不同的方式来为每一个对象创建一个唯一的标识符：可能由一个模型来自动产生 软件中内部使用，不会让它对用户可见；它可能是数据库表的一个主键，会被保证在数据库中是唯一的。只要对象从数据库中被检索，它的 会被检索出并在内存中被重建； 可能由用户创建，例如每个机场 会有一个关联的代码。每个机场拥有一个唯一的字符串 个字符串是在世界范围内通用的，被世界上的每一个旅行代理使用以标识它们的旅行计划中涉及的机场。另一种解决方案是使用对象的属性来创建标识符，当这个属性不足以代表标识符时，另一个属性就会被加入以帮助确定每一个对象。 实体在领域中是必须的对象，但是将所有的对象视为实体也会带来隐含的性能问题，因为需要对每个对象产生一个实例。 如果我们对某个对象是什么不感兴趣，只关心它拥有的属性，用它来描述领域的特殊方面、且没有标识符的一个对象，那么我可以用 值对象 。 以下列举一个经 典的例子充分体现实体和值对象的关系 ；一个客户实体一般都包含标示符，然而在客户的属性中，我们可以抽象出一个值得对象“地址”，地址这个值对象包含街道、城市、国家三个属性，这个值对象以后就可以被其他实体共享使用。 如图 图 对象 同济大学 硕士学位论文 基于 设计与实现 8 务 在领域分析和建模的过程中，我们会发现有些方面的领域是很难映射成对象的。对象要通常考虑的是拥有属性，对象会管理它的内部状态并暴露行为。在我们开发通用语言时，领域中的主要概念被引入到语言中，语言中的名词很容易被映射成对象。语言中对应那些名词的动词变成那些对 象的行为。但是有些领域中的动作，它们是一些动词，看上去却不属于任何对象。它们代表了领域中的一个重要的行为，所以不能忽略它们或者简单的把它们合并到某个实体或者值对象中。给一个对象增加这样的行为会破坏这个对象，让它看上去拥有了本该属于它的功能。但是，要使用一种面向对象语言，我们必须用到一个对象才行。我们不能只拥有一个单独的功能，它必须附属于某个对象 9。通常这种行为类的功能会跨越若干个对象，或许是不同的类。例如，为了从一个账户向另一个账户转钱，这个功能应该放到转出的账户还是在接收的账户中？感觉放在这两个中的哪 一个也不对劲。当这样的行为从领域中被识别出来时，最佳实践是将它声明成一个服务。这样的对象不再拥有内置的状态了，它的作用是为了简化所提供的领域功能。服务所能提供的协调作用是非常重要的，一个服务可以将服务于实体和值对象的相关功能进行分组。最好显式声明服务，因为它创建了领域中的一个清晰的特性，它封装了一个概念。把这样的功能放入实体或者值对象都会导致混乱，因为那些对象的立场将变得不清楚。服务担当了一个提供操作的接口。服务在技术框架中是通用的，但它们也能被运用到领域层中。一个服务不是在执行服务的对象，而与被执行操作的 对象相关。在这种情况下，一个服务通常变成了多个对象的一个链接点。这也是为什么行为很自然地依附于一个服务而不是被包含到其他领域对象的一个原因。如果这样的功能被包含进领域对象，就会在领域对象和成为操作受益者的对象之间建立起一个密集的关联网。众多对象间的高耦合度是糟糕设计的一个信号，因为这会让代码很难阅读与理解，更重要的是，这会导致很难进行变更。一个服务应该不是对通常属于领域对象的操作的替代。我们不应该为每一个需要的操作来建立一个服务。但是当一个操作凸现为一个领域中的重要概念时，就需要为它建立一个服务了。以下是服 务的 3 个特征 错误 !未找到引用源。 ： (一 ) 服务执行的操作涉及一个领域概念，这个领域概念通常不属于一个实体或者值对象。 (二 ) 被执行的操作涉及到领域中的其他的对象。 (三 ) 操作是无状态的。 块 第 2章 相关 理论 介绍 9 当领域模型随着项目的复杂度变得越来越大的时候，理解不同部件与部件之间的关系就变得十分困难。基于此原因，很有必要将模型组织进模块。模块被用来作为组织相关概念和任务以便降低复杂性的一种方法。模块在许多项目中被广泛使用。如果 要 查看模快包含的内容以及模块间的关系，就会很容易从中掌握大型模型的 概况。理解了模型间的交互之后，人们就可以开始处理模块中的细节了。因此划分模块 是管理复杂性的简单有效的方法。 另一个使用模块的原因跟代码质量有关； 软件代码应该具有高层次的内聚性和低层次的耦合度。虽然内聚开始于类和方法级别，它也可以应用于模块级别。强烈推荐将高关联度的类分组到一个模块以提供尽可能大的内聚 10。有很多类型的内聚。最常用到的两个是通信性内聚和功能性内聚。通信性内聚通常在模块的部件操作相同的数据时使用。把它们分到一组很有意义，因为它们之间存在很强的关联性。功能性内聚在模块中的部件协同工作以完成定义好 的任务时使用。这被认为是最佳的内聚类型。在设计中使用模块是一种增进内聚和消除耦合的方法。模块应该由在功能上或者逻辑上属于一体的元素构成，以保证内聚。模块应该具有定义好的接口，这些接口可以被其他的模块访问。最好用访问一个接口的方式替代调用模块中的三个对象，因为这可以降低耦合。低耦合降低了复杂性并增强了可维护性。当要执行定义好的功能时，模块间仅有极少的连接会让人很容易理解系统是如何工作的，这要比每个模块同其他的模块间存在许多关联好很多。 给定的模块名称会成为通用语言的组成部分。模块和它们的名字应该能反映对领域的深 层理解。 合 域对象在它们的生命期内会历经若干种状态，直到最后消亡。有时它们会被保存到一个永久的位置，例如数据库中，这样可以在以后的日子里被检索到，或者被存档。有时它们会被完全从系统中清除掉，包括从数据库和归档介质上。管理领域对象的生命周期自身就会遇到一个挑战，如果做得不恰当，就会对领域模型产生一个负面的影响。 聚合是一个用来定义对象所有权和边界的领域模式 错误 !未找到引用源。 。工厂和资源库是另外的两个设计模式，用来帮助我们处理对象的创建和 存储问题 。 聚合是针对数据变化可以考虑成一个单元的一组相关的对象。聚合使用边界将内部和外部的对象划分开来。每个聚合有一个根。这个根是一个实体，并且它是外部可以访问的唯一的对象。根可以保持对任意聚合对象的引用，并且其他的对象可以持有任意其他的对象，但一个外部对象只能持有根对象的引用。如果边界内有其他的实体，那些实体的标识符是本地化的，只在聚合内有意义。 同济大学 硕士学位论文 基于 设计与实现 10 聚合需要 保持数据一致性 ，其他对象只能持有根对象的引用，这意味着它们不能直接变更聚合内的其他的对象。如果根从内存中被删除或者移除，聚合内的其他所有的对象也将被删 除，因为再不会有其他的对象持有它们当中的任何一个了。 下面具体用一个实例说明问题： 如图 图 合与聚合根 上图中， 聚合的根，并且其他所有的对象都是内部的。如果需要 个它的拷贝将被传递到外部对象。 厂 单对象的创建，我们通过一个构造函数就可以解决了。然后在领域环境中，当对象的创建涉及到很多领域知识，包含诸多领域逻辑的时候，例如 关于对象内部结构的，关于所 含对象之间的关系的以及应用其上的规则等。这意味着对象的每个客户程序将持有关于对象 构建的专有知识。这破坏了领域对象和聚合的封装。如果客户程序属于应用层，领域层的一部分将被移到了外边，扰乱整个设计一个对象的创建可能是它自身的主要操作，但是复杂的组装操作不该成为被创建对象的职责。组合这样的职责会产生笨拙的设计，也很难让人理解。 因此，有必要引入一个新的概念，这个概念可以帮助封装复杂的对象创建过程，它就是工厂（ 工厂用来封装对象创建所必需的知识，它们对创建第 2章 相关 理论 介绍 11 聚合特别有用 11。当聚合的根建立时，所有聚合包含的对象将随之建立，所有的不变量得到了强化。 对应 计模式中，我们有工厂 方法和抽象工厂模式。 源库 模型驱动设计中，对象从被创建开始，直到被删除或者被归档结束，是有一个生命周期的。一个构造函数或者工厂