《领域驱动设计精粹》读书笔记之第二章《运用限界上下文与通用语言进行战略设计》

界限上下文

1. 界限上下文是语义和语境上的边界，这意味着边界内的每个代表软件模型的组件都有着特定的含义并处理特定的事务。
2. 当界限上下文被当作组织的关键举措进行开发时，该上下文即被称为核心域。
3. 核心域的识别是一个持续的精炼过程，把一堆混杂在一起的组件分离，以某种形式提炼出最重要的内容，这种形式也将使核心域更具价值。核心域的提炼是软件设计中的重中之重。
4. 不要将核心域局限在名词上，相反，应当使用 一组具体场景来表达核心域，这些场景描述了领域模型应该做的事情。这里的“场景”并不是指用例或用户故事这些软件项目中的常见概念，而是表达领域模型该如何工作，各种组件该做什么，关注的是真实场景背后的运作逻辑，相当于提炼规则，是一种抽象。
5. 限界上下文中的领域模型往往具有独立的业务价值，可以独立的提供服务。这样可以降低由于耦合造成的互相等待。
6. 软件设计中有一个常见问题，团队不清楚应该何时停止向领域模型中注入越来越多的概念，这也是系统为什么会变得越来越像大泥球的原因。因此限界上下文可以帮助我们明确领域边界及含义，防止无意识的扩张。
7. 看似相同的概念可能在不同上下文中就应该是不同的对象，如果不加以分辨就会使设计变糟。比如“客户”这个概念在不同领域中的含义可能是完全不同的。因此使用限界上下文可以让我们对相似的概念能够区分的更清晰，减少错误抽象带来的耦合。

通用语言

1. 团队在限界上下文中发展了一种语言，用于表达其边界内的软件模型，它之所以被称为通用语言，是因为每个团队成员都用它交流，软件模型实现的也是它。因此，通用语言必须严谨、精确、紧凑。
2. 通用语言凝聚着两个重要群体：领域专家（业务专家）+ 开发者
3. 产品负责人 or 领域专家：在某些情况下，可能由一个人承担两个角色，但这并不意味着产品负责人天生就是领域内的业务核心竞争力方面的专家，要确保具有专业技能、专注于业务的人员成为领域专家。领域专家类似于敏捷开发中Scrum Master，不是一个管理岗位，而更像是一个代表专业能力的职称。
4. 领域专家的心智模型将会成为通用语言的坚实基础。
5. 开发人员和领域专家都应该拒绝任何以文档为主要交流手段的倾向。最佳的通用语言是通过协作反馈循环而发展出来的，并在质疑中统一。

战略设计是必要的根基

1. 开发人员要尽量克制以技术为中心的冲动，以防无法接受以业务为中心的战略举措。
2. 开发人员要避免不由自主的进入“编码实现”的惯性思维模式，在进行战略设计时，一定要暂时搁置这些关于实现的技术细节。反之亦然，领域专家在设计阶段也不应该过度关注技术方面的问题，否则很容易被实现细节所牵绊。
3. 要专注业务复杂性而非技术复杂性。之所以采用DDD，是因为业务模型的高度复杂，我们从未想过让领域模型与其更复杂。也正是因为业务模型比项目的技术特性更加复杂，开发人员才必须与领域专家一起深入钻研业务模型。
4. 敏捷宣言中指出，工作的软件高于详尽的文档，所以不要在形式化的文档上花费过多时间，要知道文档只是为了设计出更好的软件，而不是用于树碑立传的。