DDD同时提供了战略和战术工具，来帮助你设计和实现高价值的软件。P1
DDD的战略设计工具可以帮助你和团队做出最有竞争力的软件设计选择和业务整合决策。P1
DDD的战术实施工具可以帮助设计实用的软件，它能对业务的运作方式精准建模。P1
软件项目，经常会遇到相同的情景，团队成员都在努力的维护着系统稳定，每天面对着代码和数据打补丁。 P5
- 软件开发被视为成本中心而非利润中心。
- 开发人员热衷于技术并通过技术手段解决问题，而非深入思考和设计，这会导致开发人员不断的追逐新技术。
- 过于重视数据库和数据模型，而非业务流程和运作方式。
- 对于需要根据业务命名的对象和操作，没有引起重视，而是自以为是的命名。这就导致交付的软件和业务所拥有的心智模型产生巨大的分歧。
- 业务干系人常常闭门造车，设计无人问津的需求。
- 频繁而精准的项目估算会占用大量精力和时间
- 项目中存在错误的抽象级别
- 服务集群紧耦合
如果你担心周详的设计会带来高昂的软件开发成本，那么设想一下，将来为了维护甚至修缮一套糟糕设计的软件就需要付出更为昂贵的代价。当我们把软件为左你的公司与其他公司之间的差异，并依靠它带来可观的竞争优势时，尤其如此。P7
有效设计可以满足商业组织希望借助软件超越竞争者的诉求。P7
有效设计可以驱动企业去思考哪些核心业务必须成为其竞争力，还可以指引构建正确软件模型的方向。P7
战略设计强调的是业务战略上的重点，如何按重要性分配工作，以及如何进行最佳整合。P8
限界上下文是语义和语境上的边界。这意味着边界内的每个代表软件模型的组件都有着特定的含义并处理特定的事务。P13
团队在限界上下文中发展了一种语言用于表达其边界内的软件模型，这一语言由在该限界上下文中开发软件模型的每个团队成员所使用的。这就是通用语言，团队成员间交流使用它，软件模型实现的也是它。P15
（通用语言是团队自己创建的公用语言，团队中同时包含领域专家和软件开发人员）
一个团队应该在一个限界上下文中工作，每个限界上下文应该拥有一个独立的源代码仓库。P17
团队方能实现最佳的建模成果：限界上下文与子域之间一一对应。在某些情况下，一个限界上下文中有可能存在多个子域，但这并非是最理想的建模结果。P52
子域代表的是一个单一的，有逻辑的领域模型。P52
子域的三种主要类型：核心域，支撑子域，通用子域。P53
核心域必须与其他限界上下文进行集成，这种继承关系在DDD中成为上下文映射（Context Mapping）P58
两个不同的限界上下文中存在着两种通用语言，这个关联也代表着两种语言之间的转译过程。P59
上下文映射的种类：合作关系，客户--供应商（ACL防腐层，OHS开放主机服务），
各行其道。P60
接线上下文的集成方式：基于SOAP的RPC，RESTful HTTP，消息机制。P69
消息机制应支持至少一次投递来保证所有消息最终都会被收到。这也意味着订阅方限界上下文必须实现成幂等接受者。P78
一个实体模型就是一个独立的事物。每个实体都拥有一个唯一的标识符，可以将它的个体性和所有其他类型相同或者不同的实体区分开。P86
聚合是由一个或多个实体组成，其中一个实体被称为聚合根。聚合的组成还可能包括值对象。P87
一个值对象，或则更简单的说，值，是对一个不变的概念整体所建立的模型。P87
聚合的经验法则：P91
- 在聚合边界内包婚业务规则不变性：聚合的组成部分应该由业务最终决定，而且要以那些在一次事物提交中必须保持一致的内容为基础。
- 聚合要设计的小巧：每个觉和的内容闸弄空间和事物包含范围应该相对较小。带来的另外的好处，更容易测试。
- 只能通过标识符引用其他聚合
- 使用最终一致性更新其他聚合
贫血领域模型（Anemic Domain Model），除了共有访问器（Getter和Setter）之外没有包含任何真正的业务行为。P99（一个缺少内在行为的领域对象）
对每一个即使发生的时间范围，应该坚定地考虑把两个实体恒秉到同一个聚合的边界之内。
对于每一个在给定等待时间内更新的响应聚合，将使用最终以行更新其他其他聚合。P107
领域事件是一条记录，记录着在限界上下文中发生的对业务产生重要影响的事情。P111
领域事件类型的名称应该是对过去发生的事情的陈述，即动词的过去式。P114
尽管事件通常都是用户在用户界面发起的命令导致的，但有时领域事件可能由其他原因引起，例如到期的计时器。P118
事件溯源可描述为，对所有发生在聚合实例上的领域事件进行持久化，把他们当做对聚合实例变化的记录。P119
事件风暴是一种快速的设计技术，让领域专家和开发人员都可以参与到这个快节奏的学习过程中。它聚焦于业务和业务流程，而非名词概念和数据。P124