背景与介绍
领域驱动设计全称Domain-Driven Design，简称DDD。DDD是一套综合软件系统分析和设计的面向对象建模方法，由Eric·Evans 提出。
过去系统分析和系统设计都是分离的，这样的结果导致需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，因此功能和需求背道而驰，而且软件不能快速跟随需求变化。
DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。见下面DDD与传统CRUD或过程脚本或者面向数据表等在开发效率上比较：
服务器后端发展三个阶段：
- UI+DataBase的两层架构，这种面向数据库的架构(上图table module )没有灵活性。
- UI+Service+DataBase的多层SOA(Service-Oriented Architecture)面向服务架构，这种服务+表模型的架构易使服务变得囊肿，难于维护拓展，伸缩性能差。
- DDD+SOA微服务的事件驱动的CQRS读写分离架构，应付复杂业务逻辑，以聚合模型替代数据表模型，以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展。
DDD革命性在于：领域模型准确反映了业务语言，而传统J2EE或Spring+Hibernate等事务性编程模型只关心数据，这些数据对象除了简单setter/getter方法外，没有任何业务方法，被比喻成失/贫血模型，那么领域模型这种带有业务方法的充血模型到底好在哪里？
- 让业务模型回归正常，看到领域模型代码，就看到业务需求，没有翻译没有转换，保证软件真正实现“拷贝不走样”。以比赛Match为案例比赛有“开始”和“结束”等业务行为，但是传统经典的方式是将“开始”和“结束”行为放在比赛的服务Service中，而不是放在比赛对象本身之中。
- 提供一种通用的语言，使得领域专家、产品经历和技术人员联系在一起，沟通无歧义。
DDD专门为解决复杂性而诞生，因此解决思路完全不同于传统的CRUD，但是DDD本身掌握起来并不会感觉复杂，从程序员角度看，DDD其实是研究将包含业务逻辑的ifelse语句放在哪里的学问。
DDD主要难点是领域发现和领域建模，万事开头难，除了DDD原著作提出领域统一语言外，目前用于领域发现的方法有：事件风暴、业务能力建模、领域讲故事、业务模型画布、示例映射、影响映射、Wardley Maps等。
术语
实体（Entity)
一个由它的标识定义的对象叫做实体。通常实体具有唯一id，能够持久化，具有业务逻辑，对应现实世界的业务对象。
需要注意：一些开发人员把实体当成了ORM意义上的实体，而不是业务定义的领域对象。这种在领域驱动设计中不愿在领域对象加入业务逻辑而导致的贫血模型，可能使混乱的服务对象激增。
值对象(Value Object)
值对象是一个没有概念上标识符描述一个领域方面的对象。这些对象表示临时的事物，或则可以认为值对象是实体的属性。通常值对象不具有唯一id。
聚合及聚合根(Aggregate、Aggregate Root)
聚合是用来定义领域对象所有权和边界的领域模式。聚合的作用是帮助简化模型对象间的关系。聚合，它通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚，并避免了错综复杂的难以维护的对象关系网的形成。聚合定义了一组具有内聚关系的相关对象的集合，我们把聚合看作是一个修改数据的单元。
一个聚合是一组相关的被视为整体的对象。每个聚合都有一个根对象（聚合根实体），从外部访问只能通过这个对象。根实体对象有组成聚合所有对象的引用，但是外部对象只能引用根对象实体。
只有聚合根才能使用仓储库直接查询，其它的只能通过相关的聚合访问。如果根实体被删除，聚合内部的其它对象也将被删除。
通常，我们把聚合组织到一个文件夹或一个包中。每一个聚集对应一个包，并且每个聚集成员包括实体、值对象，domain事件，仓储接口和其它工厂对象。
工厂(Factories)
厂用来封装创建一个复杂对象尤其是聚合时所需的知识，作用是将创建对象的细节隐藏起来。客户传递给工厂一些简单的参数，然后工厂可以在内部创建出一个复杂的领域对象然后返回给客户。当创建 实体和值对象复杂时建议使用工厂模式。
仓储(Repositories)
仓储是用来管理实体的集合。
仓储里面存放的对象一定是聚合，原因是domain是以聚合的概念来划分边界的；聚合作为一个整体概念，要么一起被取出来，要么一起被删除。外部访问不会单独对某个聚合内的子对象进行单独操作。因此，我们只对聚合设计仓储。
仓储还有一个重要的特征就是分为仓储定义部分和仓储实现部分，我们在领域模型中定义仓储的接口，而在基础设施层实现具体的仓储。也符合按照接口分离模式在领域层定义仓储库接口的原则。
注意：repositories本身是一种领域组件，但repositories的实现却不是领域层中的。
dao和repository在领域驱动设计中都很重要。dao是面向数据访问的，是关系型数据库和应用之间的契约。
repository：位于领域层，面向aggregation root。repository是一个独立的抽象，使用领域的通用语言，它与dao进行交互，并使用领域理解的语言提供对领域模型的数据访问服务的“业务接口”。
dao方法是细粒度的，更接近数据库，而repository方法的粒度粗一些，而且更接近领域。领域对象应该只依赖于repository接口。客户端应该始终调用领域对象，领域对象再调用dao将数据持久化到数据 存储中。
处理领域对象之间的依赖关系（比如实体及其repository之间的依赖关系）是开发人员经常遇到的典型问题。解决这个问题通 常的设计方案是让服务类或外观类直接调用repository，在调用repository的时候返回实体对象给客户端。
服务(Services)
所有的service只负责协调并委派业务逻辑给领域对象进行处理，其本身并真正实现业务逻辑，绝大部分的业务逻辑都由领域对象承载和实现了。
service可与多种组件进行交互，这些组件包括：其他的service、领域对象和repository 或 dao。
一般的领域对象都是有状态和行为的，而领域服务没有状态只有行为。需要强调的是领域服务是无状态的，它存在的意义就是协调领域对象共同完成某个操作，所有的状态还是都保存在相应的领域对象中。
domain事件
企业级应用程序事件大致可以分为三类：系统事件、应用事件和领域事件。领域事件的触发点在领域模型（domain model）中。它的作用是将领域对象从对repository或service的依赖中解脱出来，避免让领域对象对这些设施产生直接依赖。它的做法就是当领域对象的业务方法需要依赖到这些对象时就发出一个事件，这个事件会被相应的对象监听到并做出处理。
通过使用领域事件，我们可以实现领域模型对象状态的异步更新、外部系统接口的委托调用，以及通过事件派发机制实现系统集成。另外，领域事件本身具有自描述性。它不仅能够表述系统发生了什么事情，而且还能够描述发生事件的动机。
domain事件也用表进行存储。
DTO
dto- datatransfer object（数据传输对象）：dto在设计之初的主要考量是以粗粒度的数据结构减少网络通信（远程调用）并简化调用接口（接口设计）。一般用于表现层
架构
User Interface
该层包含与其他系统/客户进行交互的接口与通信设施，在多数应用里，该层可能提供包括web services、rmi或rest等在内的一种或多种通信接口。该层主要由facade、dto和assembler三类组件构成，三类组件均是典型的j2ee模式。
dto的作用最初主要是以粗粒度的数据结构减少网络通信并简化调用接口。在领域驱动设计中，采用dto模型，可以起到隐藏领域细节，帮助实现独立封闭的领域模型的作用。
dto与领域对象之间的相互转换工作多由assembler承担，也有一些系统使用反射机制自动实现dto与领域对象之间的相互转换，如apache common beanutils。
facade的用意在于为远程客户端提供粗粒度的调用接口。facade本身不处理任何的业务逻辑，它的主要工作就是将一个用户请求委派给一个或多个service进行处理，同时借助assembler将service传入或传出的领域对象转化为dto进行传输。
Application
application层中主要组件就是service。这里需要注意的是，service的组织粒度和接口设计依据与传统transaction script风格的service是一致的，但是两者的实现却有质的区别。
transaction script(事务脚本)的核心是过程，通过过程的调用来组织业务逻辑，业务逻辑在服务（service）层进行处理。大部分业务应用都可以被看成一系列事务。
transaction script的特点是简单容易理解，面向过程设计。 如果应用相对简单，在应用的生命周期里不会有基础设施技术的改变，尤其是业务逻辑很少会变动，采用transaction script风格简单自然，性能良好，容易理解。
transaction script的缺点在于，对于复杂的业务逻辑难以保持良好的设计，事务之间的冗余代码不断增多。应用架构容易出现“胖服务层”和“贫血的领域模型”。同时，service层积聚越来越多的业务逻辑，导致可维护性和扩展性变差
领域模型属于面向对象设计，领域模型具备自己的属性行为和状态，领域对象元素之间通过聚合配合解决实际业务应用。可复用，可维护，易扩展，可以采用合适的设计模型进行详细设计。缺点是相对复杂，要求设计人员有良好的抽象能力。
transactionscript风格业务逻辑主要在service中实现，而在领域驱动设计的架构里，service只负责协调并委派业务逻辑给领域对象进行处理。因此，我们可以考察这一点来识别系统是transaction script架构还是domain model架构。在实践中，设计良好的领域设计架构在开发过程中也容易向transaction script架构演变。
domain
domain层是整个系统的核心层，该层维护一个使用面向对象技术实现的领域模型，几乎全部的业务逻辑会在该层实现。domain层包含entity（实体）、valueobject(值对象)、domain event（领域事件）和repository（仓储）等多种重要的领域组件。
Infrastructure
infrastructure（基础设施层）为interfaces、application和domain三层提供支撑。所有与具体平台、框架相关的实现会在infrastructure中提供，避免三层特别是domain层掺杂进这些实现，从而“污染”领域模型。infrastructure中最常见的一类设施是对象持久化的具体实现。
实现
DDD迭代周期的项目管理模型如图所示：
设计领域模型的一般步骤：
根据需求建立一个初步的领域模型，识别出一些明显的领域概念以及它们的关联，关联可以暂时没有方向但需要有（1：1，1：n，m：n）这些关系；可以用文字精确的没有歧义的描述出每个领域概念的涵义以及包含的主要信息；
分析主要的软件应用程序功能，识别出主要的应用层的类；这样有助于及早发现哪些是应用层的职责，哪些是领域层的职责；
进一步分析领域模型，识别出哪些是实体，哪些是值对象，哪些是领域服务；
分析关联，通过对业务的更深入分析以及各种软件设计原则及性能方面的权衡，明确关联的方向或者去掉一些不需要的关联；
找出聚合边界及聚合根，这是一件很有难度的事情；因为你在分析的过程中往往会碰到很多模棱两可的难以清晰判断的选择问题，所以，需要我们平时一些分析经验的积累才能找出正确的聚合根；
为聚合根配备仓储，一般情况下是为一个聚合分配一个仓储，此时只要设计好仓储的接口即可；
走查场景，确定我们设计的领域模型能够有效地解决业务需求；
考虑如何创建领域实体或值对象，是通过工厂还是直接通过构造函数；
停下来重构模型。寻找模型中觉得有些疑问或者是蹩脚的地方，比如思考一些对象应该通过关联导航得到还是应该从仓储获取？聚合设计的是否正确？考虑模型的性能怎样，等等。
领域建模是一个不断重构，持续完善模型的过程，大家会在讨论中将变化的部分反映到模型中，从而是模型不断细化并朝正确的方向走。
从设计和实现的角度来看，典型的ddd框架应该支持以下特征。
应该是一个以pojo为基础的架构。
应该支持使用ddd概念的业务领域模型的设计和实现。
应该支持像依赖注入（di）和面向方向编程（aop）这些概念的开箱即用。
与单元测试框架整合。
与其它java/java ee框架进行良好的集成，比如jpa、hibernate、toplink等。
一些反模式：
贫血的领域对象
重复的dao
肥服务层：服务类在这里最终会包含所有的业务逻辑。
依恋情结（feature envy）：函数对某个类的兴趣高过对自己所处类的兴趣。
