第一章：什么是领域驱动设计
抛出观点：
1、领域驱动设计是一种解决大型复杂软件系统的一种设计思想、注重的是复杂问题域的构建和维护
2、强调代码模型要与业务理解的分析模型相结合，这样随着时间变化导致效用减弱，变成bbom
分析模型：描述一个软件应用程序的逻辑设计和结构，可以是示意图，也可以是uml建模语言，是一种软件的表现形式
3、缺乏组织结构，bbom就是为了快速实现功能，但是没有围绕问题域设计，导致后续的功能性扩展很难，让变更变得不可控
4、bbom模式随着时间推移，开发人员，老板都很痛苦，代码库的商业价值降低，越来越难以维护
5、设计缺乏对问题域的关注，问题域是你当前正在构建的软件的主题领域。DDD强调要专注领域高于一切的需要，问题域的专家要和开发团队一起工作，防止跑偏
如何管理复杂性
战略模式（用于提炼问题域并塑造应用程序架构）
1、DDD强调将精力和天赋专注于核心子域上的需要，核心子域是保留其最大价值和令其成功的关键
2、创建模型（满足业务用例的抽象体）
3、使用公共语言建模，主要目的是将软件模型和概念分析模型连接，从而可以让领域专家和开发团队进行协作
4、使用有界上下文防止各个功能代码模块相互污染，（有界上下文可以理解为小区的墙，整个小区可以理解为一个功能模块，小区与外部是通过小区的门进行通信的）
DDD的战术模式(或者叫构造块模式，帮助创建复杂有界上下文的有效模型的模式集合)
问题空间和解空间
问题空间可以将问题域提炼成更多可管理的子域
解空间是可以影响应用程序架构发展并让其更易于管理的模式
DDD的实践和原则
1、专注于核心子域 因为核心子域是产品成功与否的关键
2、要学会协作式学习 DDD强调开发团队与业务专家之间协作以生产出解决问题的有用模型
3、DDD老大说过，一个良好的设计都需要至少三个较差的设计，意思是不能止步于第一个有用的模型
4、通信的意思是利用通用语言，将代码模型与业务模型连接在一起，这对于业务和开发团队的协作是至关重要的
5、理解模型适用性，这里主要是说构建的模型能在上下文中被理解，并使用UL描述，这里有个问题，就是UL在不同的部分会有不同理解，通过定义上下文的语言边界来区分，类似于命名空间
6、再次强调复杂系统要围绕问题域进行开发协作
领域驱设计的常见误区
1、战术模式并不是关键，DDD强调开发前对产品的分析和协作
2、DDD并不是一套框架，在架构上具有不可知性
2、如果一个项目很少或没有领域逻辑，那么就没有必要应用DDD思想