第一篇 开篇
第一章 软件复杂度剖析
1.1 复杂度的成因
- 理解能力维度——简单的和复杂的
- 预测能力维度——有序的、复杂的和混沌的
1.2 影响理解能力维度的要素
- 规模 规模取决于需求量和需求间关系的复杂度
- 结构 结构由于质量属性导致其复杂度（满足高并发、高可用等） 系统设计可引导结构从无序到有序发展
1.3 预测能力维度
预测能力维度的要素—>变化—>应对不当—>过度设计和设计不足
感悟：对于已经知的复杂度，我们需要通过结构化的设计或者一定的抽象增强其理解能力，抽象设计的目的都是为结构化系统，降低对系统的理解难度。对于未知的复杂度（预测能力），我们需要评估系统其变化的可能性带来的收益和不变的成本。做一定的抽象设计预防或降低将来的变化对系统的影响。不同程度的抽象设计也会带来不同的成本和将来的收益，需要综合评估。
第二章 领域驱动设计概览
第三章 领域驱动设计统一过程
3.1 全局分析
- 价值需求分析
- 业务需求分析
3.2 架构映射
- 组织级映射
- 业务级映射
- 系统级映射
3.3 领域建模
- 领域分析建模
- 领域设计建模
- 领域实现建模
第二篇 全局分析
第四章 问题空间探索
- 5W模型 Who：利益相关者 Why：系统愿景 Where：系统范围 When：业务流程 What：业务服务
- 高效沟通
- 达成共识——可视化
- 统一语言
- 高效协作（商业模式画布、业务流程图、服务蓝图、用例图、事件风暴）
第五章 价值需求分析
5.1 利益相关者
5.1.1 受益者：谁会从目标系统输出的价值受益？
通常包括组织内用户、组织外用户和参与目标系统的下游第三方
5.1.2 支持者：目标系统要获得成功的输入值，需由谁来提供？
通常包括组织、组织下的相关部门与员工、投资者、监管者以及参与目标系统的上游第三方
5.1.3重要程度
在价值需求分析阶段，支持者更加重要，他们决定目标系统的愿景与范围，确定开发目标系统的约束条件； 在业务需求分析阶段，受益者更加重要，他们决定目标系统的业务流程和业务场景，前提是这些业务需求必须获得支持者的认可。
5.2 系统愿景
5.3 确定系统范围
5.4 使用商业模式画布
第六章 业务需求分析
6.1 业务流程
完整的业务流程：作者发布作品+读者阅读作品+读者评价......
6.2 业务场景
业务服务：作者发布作品或读者阅读作品或读者评价
