领域驱动的核心是建立正确的领域模型，以一种领域专家(产品经理-项目经理)、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；每一个领域都是一个业务内聚的系统(领域上下文的体现)，大大降低了各个模块的耦合。领域对象中具有自己的属性和行为，真正的按照面向对象的设计思想去设计创建对象，区别于传统setter、getter的贫血模型，能够快速适应需求的变更与二次开发。
1.1基础概念
1.1.1实体（Entity）
实体就是领域中需要唯一标识的领域概念。因为我们有时需要区分是哪个实体。有两个实体，如果唯一标识不一样，那么即便实体的其他所有属性都一样，我们也认为他们两个不同的实体；因为实体有生命周期，实体从被创建后可能会被持久化到数据库，然后某个时候又会被取出来。所以，如果我们不为实体定义一种可以唯一区分的标识，那我们就无法区分到底是这个实体还是哪个实体。另外，不应该给实体定义太多的属性或行为，而应该寻找关联，发现其他一些实体或值对象，将属性或行为转移到其他关联的实体或值对象上。比如Customer实体，他有一些地址信息，由于地址信息是一个完整的有业务含义的概念，所以，我们可以定义一个Address对象，然后把Customer的地址相关的信息转移到Address对象上。如果没有Address对象，而把这些地址信息直接放在Customer对象上，并且如果对于一些其他的类似Address的信息也都直接放在Customer上，会导致Customer对象很混乱，结构不清晰，最终导致它难以维护和理解。
1.1.2 值对象（Value Object）
在领域中，并不是每一个事物都必须有一个唯一标识，也就是说我们不关心对象是哪个，而只关心对象是什么。就以上面的地址对象Address为例，如果有两个Customer的地址信息是一样的，我们就会认为这两个Customer的地址是同一个。也就是说只要地址信息一样，我们就认为是同一个地址。用程序的方式来表达就是，如果两个对象的所有的属性的值都相同我们会认为它们是同一个对象的话，那么我们就可以把这种对象设计为值对象。因此，值对象没有唯一标识，这是它和实体的最大不同。另外值对象在判断是否是同一个对象时是通过它们的所有属性是否相同，如果相同则认为是同一个值对象；而我们在区分是否是同一个实体时，只看实体的唯一标识是否相同，而不管实体的属性是否相同；值对象另外一个明显的特征是不可变，即所有属性都是只读的。因为属性是只读的，所以可以被安全的共享；另外，我们应该给值对象设计的尽量简单，不要让它引用很多其他的对象，因为他只是一个值，就像int a = 3;那么”3”就是一个我们传统意义上所说的值，而值对象其实也可以和这里的”3”一样理解，也是一个值，只不过是用对象来表示。所以，当我们在java语言中比较两个值对象是否相等时，会重写hashCode和equals这两个方法，目的就是为了比较对象的值；值对象虽然是只读的，但是可以被整个替换掉。就像你把a的值修改为”4”(a = 4;)一样，直接把”3”这个值替换为”4”了。值对象也是一样，当你要修改Customer的Address对象引用时，不是通过Customer.Address.Street这样的方式来实现，因为值对象是只读的，它是一个完整的不可分割的整体。我们可以这样做：Customer.Address = new Address(…);
1.1.3 聚合（以及聚合根）
聚合表示一组领域对象(包括实体和值对象)，用来表述一个完整的领域概念。而每个聚合都有一个根实体，这个根实体又叫做聚合根。举个简单的例子，一个电脑包含硬盘、cpu、内存条等，这一个组合就是一个聚合，而电脑就是这个组合的聚合根。
1.1.4 领域服务（Domain Service）
领域中的一些概念不太适合建模为对象，即归类到实体对象或值对象，因为它们本质上就是一些操作，一些动作，而不是事物。这些操作或动作往往会涉及到多个领域对象，并且需要协调这些领域对象共同完成这个操作或动作。如果强行将这些操作职责分配给任何一个对象，则被分配的对象就是承担一些不该承担的职责，从而会导致对象的职责不明确很混乱。但是基于类的面向对象语言规定任何属性或行为都必须放在对象里面。所以我们需要寻找一种新的模式来表示这种跨多个对象的操作，DDD认为服务是一个很自然的范式用来对应这种跨多个对象的操作，所以就有了领域服务这个模式。和领域对象不同，领域服务是以动词开头来命名的，比如资金转帐服务可以命名为MoneyTransferService。当然，你也可以把服务理解为一个对象，但这和一般意义上的对象有些区别。因为一般的领域对象都是有状态和行为的，而领域服务没有状态只有行为。需要强调的是领域服务是无状态的，它存在的意义就是协调领域对象共完成某个操作，所有的状态还是都保存在相应的领域对象中。模型（实体）与服务（场景）是对领域的一种划分，模型关注领域的个体行为，场景关注领域的群体行为，模型关注领域的静态结构，场景关注领域的动态功能。这也符合了现实中出现的各种现象，有动有静，有独立有协作。
领域服务还有一个很重要的功能就是可以避免领域逻辑泄露到应用层。因为如果没有领域服务，那么应用层会直接调用领域对象完成本该是属于领域服务该做的操作，这样一来，领域层可能会把一部分领域知识泄露到应用层。因为应用层需要了解每个领域对象的业务功能，具有哪些信息，以及它可能会与哪些其他领域对象交互，怎么交互等一系列领域知识。因此，引入领域服务可以有效的防治领域层的逻辑泄露到应用层。对于应用层来说，从可理解的角度来讲，通过调用领域服务提供的简单易懂但意义明确的接口肯定也要比直接操纵领域对象容易的多。这里似乎也看到了领域服务具有Façade[fəˈsɑ:d]的功能。
1.1.5 仓储
领域模型中的对象自从被创建出来后不会一直留在内存中活动的，当它不活动时会被持久化到数据库中，然后当需要的时候我们会重建该对象；重建对象就是根据数据库中已存储的对象的状态重新创建对象的过程；所以，可见重建对象是一个和数据库打交道的过程。从更广义的角度来理解，我们经常会像集合一样从某个类似集合的地方根据某个条件获取一个或一些对象，往集合中添加对象或移除对象。也就是说，我们需要提供一种机制，可以提供类似集合的接口(crud)来帮助我们管理对象。仓储就是基于这样的思想被设计出来的；
仓储里面存放的对象一定是聚合，原因是之前提到的领域模型中是以聚合的概念去划分边界的；聚合是我们更新对象的一个边界，事实上我们把整个聚合看成是一个整体概念，要么一起被取出来，要么一起被删除。我们永远不会单独对某个聚合内的子对象进行单独查询或做更新操作。因此，我们只对聚合设计仓储。
仓储还有一个重要的特征就是分为仓储定义部分和仓储实现部分，在领域模型中我们定义仓储的接口，而在基础设施层实现具体的仓储。这样做的原因是：由于仓储背后的实现都是在和数据库打交道，但是我们又不希望客户（如应用层）把重点放在如何从数据库获取数据的问题上，因为这样做会导致客户（应用层）代码很混乱，很可能会因此而忽略了领域模型的存在。所以我们需要提供一个简单明了的接口，供客户使用，确保客户能以最简单的方式获取领域对象，从而可以让它专心的不会被什么数据访问代码打扰的情况下协调领域对象完成业务逻辑。这种通过接口来隔离封装变化的做法其实很常见。由于客户面对的是抽象的接口并不是具体的实现，所以我们可以随时替换仓储的真实实现，这很有助于我们做单元测试。
1.1.6 CQRS
在实际的项目中，有些时候仓储并不能高效率的完成数据的获取需求，例如在搜索页面中，根据各种搜索条件(涉及多个领域对象)进行列表的查询筛选的时候，仍然通过应用-(领域)-领域对象-仓储的方式进行查询，显然有些复杂并且效率是不高的，而且并不能清楚的划分到某个领域之中。
CQRS核心思想是将应用程序的查询部分和命令部分完全分离，这两部分可以用完全不同的模型和技术去实现。比如命令部分可以通过领域驱动设计来实现；查询部分可以直接用最快的非面向对象的方式去实现，比如用sql。这样的思想有很多好处：
1. 实现命令部分的领域模型不用经常为了领域对象可能会被如何查询而做一些折中处理；
2. 由于命令和查询是完全分离的，所以这两部分可以用不同的技术架构实现，包括数据库设计都可以分开设计，每一部分可以充分发挥其长处；
3. 高性能，命令端因为没有返回值，可以像消息队列一样接受命令，放在队列中，慢慢处理；处理完后，可以通过异步的方式通知查询端，这样查询端可以做数据同步的处理；
1.1.7应用服务
应用服务本身并不处理逻辑，但它却是领域模型的直接客户，应用服务可以用于控制持久化事务，或者向其它系统发送基于事件的消息。领域逻辑是不应该出现在应用服务中的。他主要用于协调领域层的操作。
1.1.8 领域事件
在传统项目架构中，大多是通过组合的方式，进行消息传递，这样做很方便，但是却使对象之间的耦合性增强了。例如：当User创建完成后，需要为其创建对应的cart[kɑːt]信息，通常在userService中包含了cart，创建用户完成后，调用cartService的创建cart方法。这样一旦修改了cartService的createCart方法，将会影响到userService。
领域驱动设计中，采用领域事件(发布-订阅)的方式来解决这个问题。当用户创建完成后，发布一个通知，而cart会订阅该消息通知，并进行自己的处理。User并不需要知道cart的具体创建方法。
Spring框架提供了事件通知机制的功能，通常使用@TransactionEventListener注解的方式进行开发。
1.1.8 贫血模型
传统项目中的信息体(DO,DTO,PO…)中，通常包含setter,getter方法，这样做并不符合面向对象的设计。试想，调用没有任何逻辑的set与get方法，与直接操作对象的属性(public)又有什么区别呢？setter/getter只是一种方便赋值却没有任何意义的行为。(赋值操作更加推荐使用builder模式)
1.2 设计步骤
- 根据需求建立一个初步的领域模型，识别出一些明显的领域概念以及它们的关联，关联可以暂时没有方向但需要有（1：1，1：N，M：N）这些关系；可以用文字精确的没有歧义的描述出每个领域概念的涵义以及包含的主要信息；
- 分析主要的软件应用程序功能，识别出主要的应用层的类；这样有助于及早发现哪些是应用层的职责，哪些是领域层的职责；
- 进一步分析领域模型，识别出哪些是实体，哪些是值对象，哪些是领域服务；
- 分析关联，通过对业务的更深入分析以及各种软件设计原则及性能方面的权衡，明确关联的方向或者去掉一些不需要的关联；
- 找出聚合边界及聚合根，这是一件很有难度的事情；因为你在分析的过程中往往会碰到很多模棱两可的难以清晰判断的选择问题，所以，需要我们平时一些分析经验的积累才能找出正确的聚合根；
- 为聚合根配备仓储，一般情况下是为一个聚合分配一个仓储，此时只要设计好仓储的接口即可；
- 走查场景，确定我们设计的领域模型能够有效地解决业务需求；
- 考虑如何创建领域实体或值对象，是通过工厂还是直接通过构造函数；
- 停下来重构模型。寻找模型中觉得有些疑问或者是蹩脚的地方，比如思考一些对象应该通过关联导航得到还是应该从仓储获取？聚合设计的是否正确？考虑模型的性能怎样，等等；
领域建模是一个不断重构，持续完善模型的过程，大家会在讨论中将变化的部分反映到模型中，从而是模型不断细化并朝正确的方向走。领域建模是领域专家、设计人员、开发人员之间沟通交流的过程，是大家工作和思考问题的基础。
1.3 分层示意图
1.4 扩展
四色原型分析模式
l 时刻-时间段原型（Moment-Interval Archetype）
表示在某个时刻或某一段时间内发生的某个活动。使用粉红色表示，简写为MI。
l 参与方-地点-物品原型（Part-Place-Thing Archetype）
表示参与某个活动的人或物，地点则是活动的发生地。使用绿色表示。简写为PPT。
l 描述原型（Description Archetype）
表示对PPT的本质描述。它不是PPT的分类！Description是从PPT抽象出来的不变的共性的属性的集合。使用蓝色表示，简写为DESC。
举个例子，有一个人叫张三，如果某个外星人问你张三是什么？你会怎么说？可能会说，张三是个人，但是外星人不知道“人”是什么。然后你会怎么办？你就会说：张三是个由一个头、两只手、两只脚，以及一个身体组成的客观存在。虽然这时外星人仍然不知道人是什么，但我已经可以借用这个例子向大家说明什么是“Description”了。在这个例子中，张三就是一个PPT，而“由一个头、两只手、两只脚，以及一个身体组成的客观存在”就是对张三的Description，头、手、脚、身体则是人的本质的不变的共性的属性的集合。但我们人类比较聪明，很会抽象总结和命名，已经把这个Description用一个字来代替了，那就是“人”。所以就有所谓的张三是人的说法。
l 角色原型（Role Archetype）
角色就是我们平时所理解的“身份”。使用黄色表示，简写为Role。为什么会有角色这个概念？因为有些活动，只允许具有特定角色（身份）的PPT（参与者）才能参与该活动。比如一个人只有具有教师的角色才能上课（一种活动）；一个人只有是一个合法公民才能参与选举和被选举；但是有些活动也是不需要角色的，比如一个人不需要具备任何角色就可以睡觉（一种活动）。当然，其实说人不需要角色就能睡觉也是错误的，错在哪里？因为我们可以这样理解：一个客观存在只要具有“人”的角色就能睡觉，其实这时候，我们已经把DESC当作角色来看待了。所以，其实角色这个概念是非常广的，不能用我们平时所理解的狭义的“身份”来理解，因为“教师”、“合法公民”、“人”都可以被作为角色来看待。因此，应该这样说：任何一个活动，都需要具有一定角色的参与者才能参与。 用一句话来概括四色原型就是：一个什么什么样的人或组织或物品以某种角色在某个时刻或某段时间内参与某个活动。 其中“什么什么样的”就是DESC，“人或组织或物品”就是PPT，“角色”就是Role，而”某个时刻或某段时间内的某个活动”就是MI。
