《领域驱动设计软件核心复杂性应对之道》第 1 章消化知识、第 2 章交流与语言的使用第一部分运用领域模型的三章各回答一个问题模型从哪里来第 1 章、模型怎么共享第 2 章、模型怎么落到代码里第 3 章。第 1 章 消化知识开篇论点软件的核心任务是解决领域相关问题——复杂性不在技术而在领域本身。两个基础概念模型与领域模型模型的一般含义日常经验里的模型——沙盘、航模、地图——有三个共同点简化都不是原物的复制品有选择地图只画道路河流不画土壤成分地质图恰好相反选择标准来自目的登山者的地图和司机的导航图画的是同一座山内容却完全不同。定义模型就是为某个目的对现实做有选择的简化。被选中留下的部分还被组织成了结构概念、关系、规则而不是一堆零散事实。领域是什么每个软件都服务于用户的某种活动或兴趣这个主题范围就是软件的领域。—— Eric Evans本书前言大意货运公司要解决船和货的问题——领域就是货运电路板设计工具的领域就是电路板设计。领域通常与计算机本身关系不大——这正是它难的地方。领域模型定义领域模型 对某个领域知识的**“有选择的、严格组织起来的抽象”**。它由三部分构成概念领域里的事物。PCB 领域元件实例、net、pin、探针。关系概念怎么关联。net 连接 pin探针是一种特殊的元件实例。规则 / 约束业务内在的逻辑。一个 net 的拓扑决定了信号怎么传播。三个最常见的误解1. 模型 ≠ 图。图只是表达模型的方式之一模型同样可以用代码表达、用语言表达。2. 模型 ≠ 数据库表 / 实体类。那些只是技术表达。把业务压成表和增删改查本章知识丰富的设计一节的反面教材问题恰恰在于模型失去了业务含义。3. 模型 ≠ 完整现实。选择性是模型的本质。同一个领域、不同目的模型就不同——所以正确的问题不是哪个模型是对的而是哪个模型对这个目的是对的领域模型不是某张图它是图想要传达的那套思想——不是领域专家脑子里的全部知识而是对那份知识的严格组织和选择性提炼。知识消化PCB 案例本章的核心案例给电路板设计工具加探针功能。关键在于展示的不是怎么写代码而是和工程师的对话过程探针是一种特殊元件还是带特殊属性的元件实例net 怎么表示——过程中发现Net 值得提升为一等概念。这就是知识消化的现场演示建模不是画图而是把领域专家脑中的知识咀嚼、提炼成结构化模型——靠协作、迭代、用场景检验。本章其余要点持续学习1.3 节消化不是一次性活动。知识若不沉淀进模型就会随人员流动而流失。知识丰富的设计1.4 节反面教材把业务退化成表 增删改查的团队代码无法解释业务本身。深层模型1.5 节好模型像好的航海图抓住本质关系。深层模型往往是突破的产物——这是第三部分重构加深理解的伏笔。第 2 章 交流与语言的使用问题业务术语和技术术语两套语言并行每过一道边界业务 → 分析 → 设计 → 编码就翻译一次意义层层失真模型无法被共享。模式通用语言UBIQUITOUS LANGUAGE模式定义2.1 节围绕领域模型构建一套语言从口头交流到图表、文档、代码命名全团队在所有载体上使用同一套词汇。语言随模型深化而共同演进——语言里的别扭处往往就是模型的裂缝第 9 章的伏笔。核心要求领域专家也讲这门语言开发人员不得用技术黑话搪塞——翻译即失真。配套小节大声地建模2.2 节用语言走查场景、试验措辞。命名很难但很重要。一个团队一种语言2.3 节领域专家和开发人员使用同一套语言在专家与实现之间不存在翻译层。文档和图2.4 节图是沟通工具只画主干文档应该补充代码而不是重复代码。代码是可执行地基——唯一不会过期的权威。解释性模型2.5 节为教学而简化的模型可以存在但它的词汇不得混入通用语言。两章的递进第 1 章 知识消化 → 第 2 章 通用语言 → 第 3 章 模型驱动设计第 1 章解决模型从哪里来知识消化第 2 章解决模型怎么共享语言第 3 章解决模型怎么落地代码。图、语言、代码——都是同一套思想的不同表达。一句话总结领域模型是对业务领域知识的一次**“目的明确的提炼”——把与问题相关的概念、关系、规则组织成结构通用语言让这份提炼被整个团队共享**两者最终都要落到代码里模型驱动设计。