第一章 领域驱动设计基础

1.从事务内外两个视角分析事务的方式是一套基本的逻辑分析和设计方法。

2.适度是在过度和不足中探索平衡的结果。代码适度的一个衡量标准是单一职责原则

3.面向对象还有另外一个原则DRY

4.将一些函数合并在一起的原因常常是，这些函数虽然位于在不同的类中，但是功能看起来是相同的，但是随着时间的推移，当你的注意力从函数功能本身转移到它所在的上下文时，有发现它们还是有些不同的。只有当复杂性变得难以管理或业务模型有明确要求时，才应该对抽象进行重构，提前执行此类操作只会损害代码并引入大量意外的复杂性。

5.建模过程是一种翻译再表达的过程，其唯一要点就是翻译不走样，如果翻译过程过多引入其他干扰因素和知识，那么无疑会增加翻译的难度和复制的精确性

6.ER数据建模虽然也有一套分析设计方法论，但是由于过于注重数据库技术而忽略了业务上下文，CRUD是增删改查的简称，如果使用CRUD用语替代业务用语，例如用 创建订单 替换下单， 使用 创建帖子替代发帖，使用创建发票替代开票等，虽然也容易让人明白，但是下单等用语才是真正的业务术语，业务行话，是这个行业内每个人都知晓的。作为软件系统不是取遵循这些用语习惯，而是进行转换改造，按照自己的理解生造一些词，是不是会潜移默化地将业务需求引导到不同方向呢？

7.当使用CRUD这样通用的词替代业务术语以后，最大的遗憾是丢失了术语背后的上下文。失去业务上下文后，设计的逻辑性将很难去追溯和质疑。

第二章 领域驱动战略设计

1.按照时间线发现有界上下文

2.通过领域故事或流程发现有界上下文

3.通过事件风暴发现有界上下文

3.1事件风暴不同于其他建模

     如果首先从数据建模开始，那么人们的思考和对话很快转移到模式，事务和其他与业务领域无关的事情。

     如果首先从行为建模开始，当人们将行为分解为任何并将其链接到流程时，会分心或者不知如何下手

3.2 领域事件

第三章 聚合设计

1.有界上下文中逻辑一致性这样的核心概念也必须通过聚合等领域模型来体现，这是首要设计原则。

2.如果说有界上下文解决了领域内的划分，那么聚合就解决了有界上下文内对象之间的划分。

3.业务逻辑体现在各种数据，行为的关系上，因此，聚合设计也重在关系处理，对关系的敏感性程了设计聚合的要点。

4.聚合逻辑一致性

   业务逻辑的一致性需要从两个方面去保证：业务数据和业务行为，这两方面缺一不可。

   聚合是体现逻辑一致性的地方，也是保证业务规则实现的地方。

   实现逻辑一致性是聚合存在的根目的。

5.设计聚合的几种方法

    改变主谓宾顺序

    根据领域事件设计聚合

        命令 ==》  聚合根业务逻辑（逻辑一致性）  ==》 事件

        命令是具体落到聚合根这个对象上，当聚合根据业务规则或者逻辑执行了这个命令，实际上就代表聚合内部的状态发生了改变，一些事实发送了，聚合根在抛出领域事件。

    根据单一职责设计聚合

       信息专家模式，决策控制者模型。

    按照时间边界设计聚合

    按照事务边界设计聚合

    通过ER模型设计聚合

6.有人可能要问，聚合需要保存自身数据到数据库，保存操作数据库的职责应该放在聚合中还是服务中？首先考虑，保存数据到数据库这个职责是属于业务领域还是属于技术领域？领域专家是否关心这件事？很显然它属于技术领域，它属于在聚合和数据库之间的协作者，所以将聚合的数据委托给数据库保存。如果服务中有太多协作性代码（超过20行），那么可能有一些隐藏的模型没有发现，因为协作代表了对象之间的依赖，协作越多，依赖就越多。检查这些协作活动是否涉及决策命令，如果是就要考虑是否背后有一个控制者聚合模型了。

7.奥卡姆剃刀原理

8，作为设计人员，不将领域中重要的业务逻辑明确，显示的设计出来，而是通过文档或其他交流方式告诉程序员这个方法内部的代码需要条件判断，这是很重要的业务规则，这种方式行不通。需要将业务规则明确，显示的设计出来。

9.UML类图要有主次之分，要聚焦核心。

第四章 实体和值对象

1.实体

2.值对象

   人们更习惯在代码中使用技术级别（如字符串，整数,Map,List，循环等）术语，而不是使用业务术语，这就导致人们无法从业务领域角度思考问题和查看解决问题的代码，这种脱节是造成项目失败或者复杂的一个主要原因。

3.领域服务

   服务必须是无状态的

4.隐式概念显示化