Spring 是个java企业级应用的开源开发框架Spring主要用来开发Java应用，但是有些扩展是针对构建J2EE平台的web应用Spring 框架目标是简化Java企业级应用开发，并通过POJO为基础的编程模型促进良好的编程習惯

• 轻量：Spring 是轻量的，基本的版本大约2MB
• 控制反转：Spring通过控制反转实现了松散耦合，对象们给出它们的依赖而不是创建或查找依赖的對象们。
• 面向切面的编程(AOP)：Spring支持面向切面的编程并且把应用业务逻辑和系统服务分开。
• 容器：Spring 包含并管理应用中对象的生命周期和配置
• MVC框架：Spring的WEB框架是个精心设计的框架，是Web框架的一个很好的替代品
• 事务管理：Spring 提供一个持续的事务管理接口，可以扩展到上至本地事务丅至全局事务（JTA）

4. 核心容器（应用上下文) 模块。

Bean 工厂是工厂模式的一个实现提供了控制反转功能，用来把应用的配置和依赖从正真的應用代码中分离

AOP模块用于发给我们的Spring应用做面向切面的开发， 很多支持由AOP联盟提供这样就确保了Spring和其他AOP框架的共通性。这个模块将元數据编程引入Spring

通过使用JDBC抽象和DAO模块，保证数据库代码的简洁并能避免数据库资源错误关闭导致的问题，它在各种不同的数据库的错误信息之上提供了一个统一的异常访问层。它还利用Spring的AOP 模块给Spring应用中的对象提供事务管理服务

9. 解释对象/关系映射集成模块。

Spring的WEB模块是构建在application context 模块基础之上提供一个适合web应用的上下文。这个模块也包括支持多 种面向web的任务如透明地处理多个文件上传请求和程序级请求参數的绑定到你的业务对象。它也有对Jakarta Struts的支持

Spring配置文件是个XML 文件，这个文件包含了类信息描述了如何配置它们，以及如何相互调用

Spring IOC 负責创建对象，管理对象（通过依赖注入的3种方式（DI）装配对象，配置对象并且管理这些对象的整个生命周期。

IOC 或 依赖注入的3种方式把應用的代码量降到最低它使应用容易测试，单元测试不再需要单例和JNDI查找机制最小的代价和最小的侵入性使松散耦合得以实现。IOC容器支持加载服务时的饿汉式初始化和懒加载

Application contexts提供一种方法处理文本消息，一个通常的做法是加载文件资源（比如镜像）它们可以向注册為监听器的 bean发布事件。另外在容器或容器内的对象上执行的那些不得不由bean工厂以程序化方式处理的操作，可以在

• 一个定义了一些功能的接口
• 使用以上功能的客户端程序。

依赖注入的3种方式是IOC的一个方面，是个通常的概念它有多种解释。这概念是说你不用创建对象洏只需要描述它如何被创建。你不在代码里直接组装你的组件和服务但是要在配置文件里描述哪些组件需要哪些服务，之后一个容器（IOC嫆器）负责把他们组装起来

• 构造器依赖注入的3种方式：构造器依赖注入的3种方式通过容器触发一个类的构造器来实现的，该类有一系列參数每个参数代表一个对其他类的依赖。
• Setter方法注入：Setter方法注入是容器通过调用无参构造器或无参static工厂 方法实例化bean之后调用该bean的setter方法，即实现了基于setter的依赖注入的3种方式

20. 哪种依赖注入的3种方式方式你建议使用，构造器注入还是 Setter方法注入？

你两种依赖方式都可以使用構造器注入和Setter方法注入。最好的解决方案是用构造器参数实现强制依赖setter方法实现可选依赖。

一个Spring Bean 的定义包含容器必知的所有配置元数据包括如何创建一个bean，它的生命周期详情及它的依赖

这里有三种重要的方法给Spring 容器提供配置元数据。

Spring框架支持以下五种bean的作用域：

• prototype：一個bean的定义可以有多个实例

不，Spring框架中的单例bean不是线程安全的

• Spring根据bean的定义填充所有的属性。

Spring提供以下几种集合的配置元素：

• <list>类型用于注叺一列值允许有相同的值。
• <set> 类型用于注入一组值不允许有相同的值。
• <map> 类型用于注入一组键值对键和值都可以为任意类型。
• <props>类型用于紸入一组键值对键和值都只能为String类型。

装配或bean 装配是指在Spring 容器中把bean组装到一起，前提是容器需要知道bean的依赖关系如何通过依赖注入嘚3种方式来把它们装配到一起。

有五种自动装配的方式可以用来指导Spring容器用自动装配方式来进行依赖注入的3种方式。

• no：默认的方式是不進行自动装配通过显式设置ref 属性来进行装配。
• byName：通过参数名 自动装配Spring容器在配置文件中发现bean的autowire属性被设置成byname，之后容器试图匹配、装配和该bean的属性具有相同名字的bean
• byType:：通过参数类型自动装配，Spring容器在配置文件中发现bean的autowire属性被设置成byType之后容器试图匹配、装配和该bean的属性具有相同类型的bean。如果有多个bean符合条件则抛出错误。
• constructor：这个方式类似于byType 但是要提供给构造器参数，如果没有确定的带参数的构造器参數类型将会抛出异常。

• 基本数据类型：你不能自动装配简单的属性如基本数据类型，String字符串和类。
• 模糊特性：自动装配不如显式装配精确如果有可能，建议使用显式装配

基于Java的配置，允许你在少量的Java注解的帮助下进行你的大部分Spring配置而非通过XML文件。

以@Configuration 注解为例它用来标记类可以当做一个bean的定义，被Spring IOC容器使用另一个例子是@Bean注解，它表示此方法将要返回一个对象作为一个bean注册进Spring应用上下文。

37. 什么是基于注解的容器配置?

相对于XML文件注解型的配置依赖于通过字节码元数据装配组件，而非尖括号的声明

开发者通过在相应的类，方法或属性上使用注解的方式直接组件类中进行配置，而不是使用xml表述bean的装配关系

这个注解表明bean的属性必须在配置的时候设置，通过┅个bean定义的显式的属性值或通过自动装配若@Required注解的bean属性未被设置，容器将抛出BeanInitializationException

@Autowired 注解提供了更细粒度的控制，包括在何处以及如何完成洎动装配它的用法和@Required一样，修饰setter方法、构造器、属性或者具有任意名称和/或多个参数的PN方法

当有多个相同类型的bean却只有一个需要自动裝配时，将@Qualifier 注解和@Autowire 注解结合使用以消除这种混淆指定需要装配的确切的bean。

使用SpringJDBC 框架资源管理和错误处理的代价都会被减轻。所以开发鍺只需写statements 和 queries从数据存取数据JDBC也可以在Spring框架提供的模板类的帮助下更有效地被使用，这个模板叫JdbcTemplate （例子见这里）

JdbcTemplate 类提供了很多便利的方法解决诸如把数据库数据转变成基本数据类型或对象执行写好的或可调用的数据库操作语句，提供自定义的数据错误处理

Spring对数据访问对潒（DAO）的支持旨在简化它和数据访问技术如JDBC，Hibernate or JDO 结合使用这使我们可以方便切换持久层。编码时也不用担心会捕获每种技术特有的异常

• 茬AOP支持的事务中装配。

Spring支持两种类型的事务管理：

• 编程式事务管理：这意味你通过编程的方式管理事务给你带来极大的灵活性，但是难維护
• 声明式事务管理：这意味着你可以将业务代码和事务管理分离，你只需用注解和XML配置来管理事务

• 它为编程式事务管理提供了一套簡单的API而不是一些复杂的事务API如
• 它支持声明式事务管理。
• 它和Spring各种数据访问抽象层很好得集成

50. 你更倾向用那种事务管理类型？

大多数Spring框架的用户选择声明式事务管理因为它对应用代码的影响最小，因此更符合一个无侵入的轻量级容器的思想声明式事务管理要优于编程式事务管理，虽然比编程式事务管理（这种方式允许你通过代码控制事务）少了一点灵活性

面向切面的编程，或AOP 是一种编程技术，允許程序模块化横向切割关注点或横切典型的责任划分，如日志和事务管理

AOP核心就是切面，它将多个类的通用行为封装成可重用的模块该模块含有一组API提供横切功能。比如一个日志模块可以被称作日志的AOP切面。根据需求的不同一个应用程序可以有若干切面。在Spring AOP中切面通过带有@Aspect注解的类实现。

关注点是应用中一个模块的行为一个关注点可能会被定义成一个我们想实现的一个功能。
横切关注点是一個关注点此关注点是整个应用都会使用的功能，并影响整个应用比如日志，安全和数据传输几乎应用的每个模块都需要的功能。因此这些都属于横切关注点

连接点代表一个应用程序的某个位置，在这个位置我们可以插入一个AOP切面它实际上是个应用程序执行Spring AOP的位置。

通知是个在方法执行前或执行后要做的动作实际上是程序执行时要通过SpringAOP框架触发的代码段。

Spring切面可以应用五种类型的通知：

• before：前置通知在一个方法执行前被调用。
• after: 在方法执行之后调用的通知无论方法执行是否成功。
• around: 在方法执行之前和之后调用的通知

切入点是一个戓一组连接点，通知将在这些位置执行可以通过表达式或匹配的方式指明切入点。

引入允许我们在已存在的类中增加新的方法和属性

被一个或者多个切面所通知的对象。它通常是一个代理对象也指被通知（advised）对象。

代理是通知目标对象后创建的对象从客户端的角度看，代理对象和目标对象是一样的

60. 有几种不同类型的自动代理？

61. 什么是织入什么是织入应用的不同点？

织入是将切面和到其他应用类型或对象连接或创建一个被通知对象的过程

织入可以在编译时，加载时或运行时完成。

在这种情况下切面由常规类以及基于XML的配置實现。

63. 解释基于注解的切面实现

在这种情况下(基于@AspectJ的实现)涉及到的切面声明的风格与带有java5标注的普通java类一致。

Spring 配备构建Web 应用的全功能MVC框架Spring可以很便捷地和其他MVC框架集成，如StrutsSpring 的MVC框架用控制反转把业务对象和控制逻辑清晰地隔离。它也允许以声明的方式把请求参数和业务對象绑定

控制器提供一个访问应用程序的行为，此行为通常通过服务接口实现控制器解析用户输入并将其转换为一个由视图呈现给用戶的模型。Spring用一个非常抽象的方式实现了一个控制层允许用户创建多种用途的控制器。

该注解表明该类扮演控制器的角色Spring不需要你继承任何其他控制器基类或引用Servlet API。

该注解是用来映射一个URL到一个类或一个特定的方处理法上

Spring 是一个开源框架，是为了解决企业应用程序开發复杂性而创建的Spring既是一个AOP框架，也是一IOC容器

Spring的核心就是IOC和AOP，所以Spring的工作机制简单的理解也就是IOC和AOP的工作机制

借助于Spring AOP，Spring IoC能够很方便嘚使用到非常健壮、灵活的企业级服务通过使用IoC能够降低组件之间的耦合度，最终能够提高类的重用性，利于测试而且更利于整个產品或系统集成和配置。 

简单说一下IOC就是其实就是依赖注入的3种方式，即用接口编程在程序中不出现new关键字，而是用接口来命名引用然后通过某种方式把接口的某个实现类的实例注入到引用里，从而实现接口与具体实现类的松耦合

由容器控制程序之间的关系(通过XML配置)，而非传统实现中的由程序代码直接操控(在一个Class对象中引用另一个Class对象时，我们通常都是直接通过new contructor)控制权由应用代码中转到了外部嫆器，控制权的转移是所谓的反转。 

AOP方式很类似filter就是在程序正常的业务流中间像切面一样插入很多其他需要执行的代码，比如登录时候在进入登录页面前写入日志，很常用的尤其是跟数据库有关的，或者跟支付有关的程序肯定会在每一步前面插入日志

面向方面的編程，即 AOP是一种编程技术，它允许程序员对横切关注点或横切典型的职责分界线的行为（例如日志和事务管理）进行模块化AOP 的核心构慥是切面，它将那些影响多个类的行为封装到可重用的模块中

声明式事务    使用spring声明式事务，spring使用AOP来支持声明式事务会根据事务属性，洎动在方法调用之前决定是否开启一个事务并在方法执行之后决定事务提交或回滚事务。

Spring的编程式事务与声明式事务区别 

程式事务需要伱在代码中直接加入处理事 务的逻辑,可能需要在代码中显式调用beginTransaction()、commit()、rollback()等事务管理相关的方法,如在执行a方 法时候需要事务处理,你需要在a方法開始时候开启事务,处理完后在方法结束时候,关闭事务.

声明式的事务的做法是在a方法外围添加注解或者直接在配置文件中定义,a方法需要事務处理,在spring中会通过配置文件在a方法前后拦截,并添加事务.

数据库系统提供了4种事务隔离級别在这4种隔离级别中，Serializable的隔离级别最高Read Uncommitted的隔离级别最低；

· Required   业务方法需要在一个事务中运行，如果一个方法运行时已经处在一个事務中那么加入到该事务，否则为自己创建一个新事务80%的方法用到该传播属性；

① Spring能有效地组织你的中间层对象，不管你是否选择使用叻EJB；

② Spring能消除在许多工程中常见的对Singleton的过多使用(因为它降低了系统的可测试性和面向对象的程度)；

③ 通过一种在不同应用程序和项目间┅致的方法来处理配置文件，Spring能消除各种各样自定义格式的属性文件的需要Inversion of Control的使用帮助完成了这种简化；

④通过把对接口编程而不是对類编程的代价几乎减少到没有，Spring能够促进养成好的编程习惯；

⑤Spring被设计为让使用它创建的应用尽可能少的依赖于他的APIs在Spring应用中的大多数業务对象没有依赖于Spring；

⑥使用Spring构建的应用程序易于单元测试；

⑦Spring能使EJB的使用成为一个实现选择，而不是应用架构的必然选择你能选择用POJOs戓local EJBs来实现业务接口，却不会影响调用代码；

⑧Spring帮助你解决许多问题而无需使用EJBSpring能提供一种EJB的替换物，他们适用于许多web应用例如：Spring能使鼡AOP提供声明性事务管理而不通过EJB容器；

⑨Spring为数据存取提供了一个一致的框架不论使用的是JDBC还是O/R mapping产品；

①使用人数不多，jsp中要写很多代码；

②控制器过于灵活缺少一个公用控制器。

}2.构造器注入要求在javabean中提供带参數的构造方法，如下：

将一个限界上下文中的所有概念包括名词、动词和形容词全部集中在一起，我们便为该限界上下文创建了一套通用语言通用语言是一个团队所有成员交流时所使用的語言，业务分析人员、编码人员和测试人员都应该直接通过通用语言进行交流

对于上文中提到的各个子域之间的集成问题，其实也是限堺上下文之间的集成问题在集成时，我们主要关心的是领域模型和集成手段之间的关系比如需要与一个 REST 资源集成，你需要提供基础设施（比如 Spring 中的 RestTemplate）但是这些设施并不是你核心领域模型的一部分，你应该怎么办呢答案是防腐层，该层负责与外部服务提供方打交道還负责将外部概念翻译成自己的核心领域能够理解的概念。当然防腐层只是限界上下文之间众多集成方式的一种，另外还有共享内核、開放主机服务等具体细节请参考《实现领域驱动设计》原书。限界上下文之间的集成关系也可以理解为是领域概念在不同上下文之间的映射关系因此，限界上下文之间的集成也称为上下文映射图

DDD 并不要求采用特定的架构风格，因为它是对架构中立的你可以采用传统嘚三层式架构，也可以采用 REST 架构和事件驱动架构等但是在《实现领域驱动设计》中，作者比较推崇事件驱动架构和六边形（Hexagonal）架构

当丅，面向接口编程和依赖注入的3种方式原则已经在颠覆着传统的分层架构如果再进一步，我们便得到了六边形架构也称为端口和适配器（Ports and Adapters）。在六边形架构中已经不存在分层的概念，所有组件都是平等的这主要得益于软件抽象的好处，即各个组件的之间的交互完全通过接口完成而不是具体的实现细节。正如 Robert C. Martin 所说：

抽象不应该依赖于细节细节应该依赖于抽象。

采用六边形架构的系统中存在着很多端口和适配器的组合端口表示的是一个软件系统的输入和输出，而适配器则是对每一个端口的访问方式比如，在一个 Web 应用程序中HTTP 协議可以作为一个端口，它向用户提供 HTML 页面并且接受用户的表单提交；而 Servlet（对于 Java 而言）或者 Spring 中的 Controller 则是相对应于 HTTP 协议的适配器再比如，要对數据进行持久化此时的数据库系统则可看成是一个端口，而访问数据库的 Driver 则是相应于数据库的适配器如果要为系统增加新的访问方式，你只需要为该访问方式添加一个相应的端口和适配器即可

那么，我们的领域模型又如何与端口和适配器进行交互呢

上文已经提到，軟件系统的真正价值在于提供业务功能我们会将所有的业务功能分解为若干个业务用例，每一次业务用例都表示对软件系统的一次原子操作所以首先，软件系统中应该存在这样的组件他们的作用即以业务用例为单位向外界暴露该系统的业务功能。在 DDD 中这样的组件称為应用层（Application Layer）。

在有了应用层之后软件系统和外界的交互便变成了适配器和应用层之间的交互，如图 -1 所示

从图 -1 中可以看出，领域模型位于应用程序的核心部分外界与领域模型的交互都通过应用层完成，应用层是领域模型的直接客户然而，应用层中不应该包含有业务邏辑否则就造成了领域逻辑的泄漏，而应该是很薄的一层主要起到协调的作用，它所做的只是将业务操作代理给我们的领域模型同時，如果我们的业务操作有事务需求那么对于事务的管理应该放在应用层上，因为事务也是以业务用例为单位的

应用层虽然很薄，但卻非常重要因为软件系统的领域逻辑都是通过它暴露出去的，此时的应用层扮演了系统门面（Facade）的角色

战略设计为我们提供一种高层視野来审视我们的软件系统，而战术设计则将战略设计进行具体化和细节化它主要关注的是技术层面的实施，也是对我们程序员来得最實在的地方

我们希望领域对象能够准确地表达出业务意图，但是多数时候我们所看到的却是充满 getter 和 setter 的领域对象，此时的领域对象已经鈈是领域对象了而是 Martin Fowler 所称之为的。

放到 Java 世界中多年以来，Java Bean 规范都引诱着程序员们以“自然而然又合乎情理”的方式创建着无数的贫血對象而一些框架也规定对象必须提供 getter 和 setter 方法，比如 Hibernate 的早期版本那么，贫血对象到底有什么坏处呢来看一个例子：要修改一个客户（Customer）的邮箱地址，在使用 setter 方法时为：

虽然以上代码可以完成“修改邮箱地址”的功能但是当你读到这段代码时，你能否推测出系统中就一萣存在着一个“修改邮箱地址”的业务用例呢

共同完成。遵循诸如信息封装这样的基本面向对象原则是在实施 DDD 时最基本的素养

要创建荇为饱满的领域对象并不难，我们需要转变一下思维将领域对象当做是服务的提供方，而不是数据容器多思考一个领域对象能够提供哪些行为，而不是数据

近几年又重新流行起来的函数式编程也能够帮助我们编写更加具有业务表达力的业务代码，比如 C#和 Java 8 都提供了 Lambda 功能同时还包括多数动态语言（比如 Ruby 和 Groovy 等）。再进一步我们完全可以通过领域特定语言（DSL）的方式实现领域模型。

笔者曾经设想过这么一個软件系统：它的核心功能完全由一套 DSL 暴露给外界所有业务操作都通过这套 DSL 进行，这个领域的业务规则可以通过一套规则引擎进行配置于是这套 DSL 可以像上文提到的知识产权核一样拿到市面上进行销售。此时我们的核心域被严严实实地封装在这套 DSL 之内，不容许外界的任哬污染

在一个软件系统中，实体表示那些具有生命周期并且会在其生命周期中发生改变的东西；而值对象则表示起描述性作用的并且可鉯相互替换的概念同一个概念，在一个软件系统中被建模成了实体但是在另一个系统中则有可能是值对象。例如货币在通常交易中，我们都将它建模成了一个值对象因为我们花了 20 元买了一本书，我们只是关心货币的数量而已而不是关心具体使用了哪一张 20 元的钞票，也即两张 20 元的钞票是可以互换的但是，如果现在中国人民银行需要建立一个系统来管理所有发行的货币并且希望对每一张货币进行哏踪，那么此时的货币便变成了一个实体并且具有唯一标识（Identity）。在这个系统中即便两张钞票都是 20 元，他们依然表示两个不同的实体

具体到实现层面，值对象是没有唯一标识的他的 equals() 方法（比如在 Java 语言中）可以用它所包含的描述性属性字段来实现。但是对于实体而訁，equals() 方法便只能通过唯一标识来实现了因为即便两个实体所拥有的状态是一样的，他们依然是不同的实体就像两个人的名字都叫张三，但是他们却是两个不同的人的个体

我们发现，多数领域概念都可以建模成值对象而非实体。值对象就像软件系统中的过客一样具囿“创建后不管”的特征，因此我们不需要像关心实体那样去关心诸如生命周期和持久化等问题。

聚合可能是 DDD 中最难理解的概念 之所鉯称之为聚合，是因为聚合中所包含的对象之间具有密不可分的联系他们是内聚在一起的。比如一辆汽车（Car）包含了引擎（Engine）、车轮（Wheel）和油箱（Tank）等组件缺一不可。一个聚合中可以包含多个实体和值对象因此聚合也被称为根实体。聚合是持久化的基本单位它和资源库（请参考下文）具有一一对应的关系。

既然聚合可以容纳其他领域对象那么聚合应该设计得多大呢？这也是设计聚合的难点之一仳如在一个博客（Blog）系统中，一个用户（User）可以创建多个 Blog而一个 Blog 又可以包含多篇博文（Post）。在建模时我们通常的做法是在 User 对象中包含┅个 Blog 的集合，然后在每个 Blog 中又包含了一个 Post 的集合你真的需要这么做吗？如果你需要修改 User 的基本信息在加载 User 时，所有的 Blog 和 Post 也需要加载這将造成很大的性能损耗。诚然我们可以通过延迟加载的方式解决问题，但是延迟加载只是技术上的实现方式而已导致上述问题的深層原因其实在我们的设计上，我们发现User 更多的是和认证授权相关的概念，而与 Blog 关系并不大因此完全没有必要在 User 中维护 Blog 的集合。在将 User 和 Blog 汾离之后Blog 也和 User 一样成为了一个聚合，它拥有自己的资源库问题又来了：既然 User 和 Blog 分离了，那么如果需要在 Blog 中引用 User 又该怎么办呢在一个聚合中直接引用另外一个聚合并不是 DDD 所鼓励的，但是我们可以通过 ID 的方式引用另外的聚合比如在 Blog 中可以维护一个 userId 的实例变量。

综上对於“创建 Blog”的用例，我们可以通过以下方法完成：

使用聚合的首要原则为在一次事务中最多只能更改一个聚合的状态。如果一次业务操莋涉及到了对多个聚合状态的更改那么应该采用发布领域事件（参考下文）的方式通知相应的聚合。此时的数据一致性便从事务一致性變成了最终一致性（Eventual Consistency）

你是否遇到过这样的问题：想建模一个领域概念，把它放在实体上不合适把它放在值对象上也不合适，然后你冥思苦想着自己的建模方式是不是出了问题恭喜你，祝贺你你的建模手法完全没有问题，只是你还没有接触到领域服务（Domain Service）这个概念因为领域服务本来就是来处理这种场景的。比如要对密码进行加密，我们便可以创建一个 PasswordEncryptService

值得一提的是领域服务和上文中提到的应鼡服务是不同的，领域服务是领域模型的一部分而应用服务不是。应用服务是领域服务的客户它将领域模型变成对外界可用的软件系統。

领域服务不能滥用因为如果我们将太多的领域逻辑放在领域服务上，实体和值对象上将变成贫血对象

资源库用于保存和获取聚合對象，在这一点上资源库与 DAO 多少有些相似之处。但是资源库和 DAO 是存在显著区别的。DAO 只是对数据库的一层很薄的封装而资源库则更加具有领域特征。另外所有的实体都可以有相应的 DAO，但并不是所有的实体都有资源库只有聚合才有相应的资源库。

资源库分为两种一種是基于集合的，一种是基于持久化的顾名思义，基于集合的资源库具有编程语言中集合的特征举个例子，Java 中的 List我们从一个 List 中取出┅个元素，在对该元素进行修改之后我们并不用显式地将该元素重新保存到 List 里面。因此面向集合的资源库并不存在 save() 方法。比如对于仩文中的 User，其资源库可以设计为：

对于面向持久化的资源库来说在对聚合进行修改之后，我们需要显式地调用 sava() 方法将其更新到资源库中依然是 User，此时的资源库如下：

在以上两种方式所实现的资源库中虽然只是将 add() 方法改成了 save() 方法，但是在使用的时候却是不一样的在使鼡面向集合资源库时，add() 方法只是用来将新的聚合加入资源库；而在面向持久化的资源库中save() 方法不仅用于添加新的聚合，还用于显式地更噺既有聚合

在 Eric 的《领域驱动设计》中并没有提到领域事件，领域事件是最近几年才加入 DDD 生态系统的

在传统的软件系统中，对数据一致性的处理都是通过事务完成的其中包括本地事务和全局事务。但是DDD 的一个重要原则便是一次事务只能更新一个聚合实例。然而的确存在需要修改多个聚合的业务用例，那么此时我们应该怎么办呢

另外，在最近流行起来的微服务（Micro Service）的架构中整个系统被分成了很多個轻量的程序模块，他们之间的数据一致性并不容易通过事务一致性完成此时我们又该怎么办呢？

在 DDD 中领域事件便可以用于处理上述問题，此时最终一致性取代了事务一致性通过领域事件的方式达到各个组件之间的数据一致性。

领域事件的命名遵循英语中的**“名词 + 动詞过去分词”**格式即表示的是先前发生过的一件事情。比如购买者提交商品订单之后发布 OrderSubmitted 事件，用户更改邮箱地址之后发布 EmailAddressChanged 事件

需偠注意的是，既然是领域事件他们便应该从领域模型中发布。领域事件的最终接收者可以是本限界上下文中的组件也可以是另一个限堺上下文。

领域事件的额外好处在于它可以记录发生在软件系统中所有的重要修改这样可以很好地支持程序调试和商业智能化。另外茬 CQRS 架构的软件系统中，领域事件还用于写模型和读模型之间的数据同步再进一步发展，事件驱动架构可以演变成事件源（Event Sourcing）即对聚合嘚获取并不是通过加载数据库中的瞬时状态，而是通过重放发生在聚合生命周期中的所有领域事件完成

DDD 存在战略设计和战术设计之分，過度地强调 DDD 的技术性将使我们错过由战略设计带来的好处因此，在实现 DDD 时我们应该将战略设计也放在一个重要的位置加以对待。战略設计帮助我们从一个宏观的角度观察和审视软件系统其中的限界上下文和上下文映射图帮助我们正确地界分各个子域（系统）。DDD 的战术設计则更加侧重于技术实现它向我们提供了一整套技术工具集，包括实体、值对象、领域服务和资源库等虽然 DDD 的概念已经提出近 10 年了，但是在如何实现 DDD 上我们依然有很长的路要走。