从需求分析到业务上线

• 领域模型反映了问题域的认知
• 领域模型决定业务响应能力
• 演进式思维和高质量领域模型
• 从需求到代码，卓越技术实践概览

认知问题是软件开发的根本问题
领域模型反映了问题域的认知

领域模型定义了领域内的关键概念以及这些概念之间的关系

• 领域模型是概念模型
• 领域模型描述的是现实世界的事物和他们之间的关系
• 领域模型和软件无关，反映的是问题空间的本质理解

通过提升认知，更好支持业务

高质量领域模型提升业务响应能力

积累的是资产和债务，是研发效率的分水岭

小结

领域模型反映了问题认知

• 认知是企业的核心资产
• 深度认知带来更顺畅的需求沟通
• 深度认知带来更好的产品架构

领域模型和领域资产有重要关联

• 好的领域模型反映业务本质
• 好的领域模型带来更好的业务响应

缺乏领域模型的一些信号

• 组织中没有关于概念的共识
• 沟通误解和不必要的需求变更
• 看似容易支持的业务设计到系统的很多改动点
• 架构可理解性和可维护性不足，容易发生意料之外的问题

高质量领域模型源自演进

领域模型反映了问题域的认知
认知问题本来就是渐进的

科学发现，是一个不断否定、逐步求精的过程

领域模型是一种假说，需要持续检验
产生洞察

确保领域模型可以持续演进
并不存在所谓「正确」的领域模型，
只是说当前的领域模型经过了场景的检验，而且最为优雅

领域模型是深层模型

“有用的模型很少停留在表面层次上。随着对领域模型和应用的理解逐步加深，我们往往会丢掉那些最初看起来很重要的表面元素，或者切换他们的角度。
这样，一些在开始时不可能发现的巧妙抽象就会浮出水面，而他们恰恰切中问题的要害。”
Eric Evans

以领域模型为中心的实践体系
需求 - 设计 -实现

建立统一语言

除非做到统一语言，否则领域模型并不是真正的模型

• 一个简单规则：任何在需求描述中出现的概念，都必须在领域模型中。如果需求描述中存在概念之间的关系，领域模型也必须有这个关系。

• 将模型作为语言的中心，确保团队在所有的交流活动和代码中坚持使用这种语言。在画图、写文档和说话时也采用这种语言。

• 试着尝试修改模型以及对应的语言表达来消除不自然的地方（响应的也要修改代码，包括模块名、类名、方法等）

在白板上可视化领域模型

领域模型是关于认知的，它体现在每天的具体工作中。
如果领域模型只是活在 PPT 里，它并不是真正的领域模型。

关键信息

• 软件开发的困难与生俱来

  • 需求分析、架构设计、软件实现和质量保证，是软件开发的关键要素

• 领域模型非常重要

  • 高质量的认知，也就是领域模型，可以有效降低复杂性，提升业务响应能力
  • 认知层次不同，开发的效率差异巨大

• 演进式的思维模型

  • 认知需要渐进，深度模型的建立非一朝一夕
  • 领域模型需要持续演进，适应认知的规律

• 技术实践的本质是“实践”

  • 如何表达领域模型
  • 如何让领域模型真正发挥作用，而不是停留在PPT上？

下节课预告

• 通过协作和演进式建模，获得高质量和有共识的领域模型
  • 把概念写下来
  • 场景驱动和检验
  • 业务视角
  • 分解和抽象
• 关联的实践
  • 用例驱动的分析、实例化需求、事件风暴、统一语言