领域驱动设计（读书笔记）

• 模型和实现的绑定：领域和实现和设计紧密绑定
• 模型语言：领域专家和开发人员之间的沟通语言
• 开发一个蕴含丰富知识的模型：模型不是静态的数据，而是包含了丰富的知识
• 提炼模型：整合模型（增删），丢弃不需要/不重要的概念
• 头脑风暴和实验：模型实验室，通过和领域专家之间的互动，借助语言和草图，创造出有价值的模型（不断的反馈和训练）

评价一个软件团队的有效性

传统的瀑布模型

• 程序员只理解功能，而不理解背后的原理，所以通过重构来保持软件良好地扩展。

模型必须是精确的

• 模型是经过领域专家和开发团队消化、走查后确定下来的，不严谨的模型会导致返工、加班、扯皮、失败。
• 模型会经历演化

怎么保持团队的高效率

• 随着时间变化，团队人员变动，领域知识会逐渐丢失
• 关键是形成组织，铁打的营盘，流水的兵。组织的关键是保持反馈闭环。
• 高效率的组织保证模型的及时演化

领域驱动设计方法中，软件的参与方：

1. 开发人员
2. 领域专家
3. 用户

软件的组成：

1. 核心领域：需要达成共识，并持续进行维护
2. 基础设施

领域驱动方法中，模型的演化导致重构

领域的核型，不仅仅是一些名词概念，也包含业务规则和活动。
领域专家的脑袋中，业务规则的应用往往很复杂，领域专家可能会给出最常见场景的一些规则，仅使用这些规则来处理实际场景是不够的。

领域专家也许不会意识到自己在应用规则来处理问题时，思考的过程会有多么的复杂

例如：

• 规则之间的矛盾
• 使用常识来弥补规则

需要领域专家和开发人员的紧密合作来理清和提炼业务规则，消除其中的矛盾，去除无用的部分。

超卖规则的实现

1. 卫语句
   • 不明确的，不懂业务的开发人员很难把代码和需求关联起来
   • 领域专家很难捕捉到这个规则（没有明确的业务含义）
2. 抽象一个OverBookingPolicy
   • 尽管命名中策略通常是策略模式时才会采用，这里策略也是业务中的术语，属于业务概念，因此仍然使用这个命名
   • 明确超卖是一种策略
   • 超卖的规则实现独立且明确
   • 明确超卖是一种业务规则，并不是一个不起眼的卫语句
   • 领域专家能捕捉到这个规则，因此容易形成反馈闭环

有用的模型很少停留在表面，随着对领域和需求的理解加深…一些开始时不可能发现的抽象就会浮出水面，而它们恰恰切中问题的要害。

知识消化是一种探索，它永无止境

领域模型是软件项目的公共语言的核心

模型是人们头脑中形成的与项目有关的概念集合，术语和相互关系提供了模型语言的语义。

模型语言十分精确，是专门为领域量身裁剪的。

模型与代码应当紧绑定。

困难所在：

1. 每个开发人员形成自己的抽象，但领域专家不理解这些抽象
2. 领域专家有自己的行话，但由于存在语言上的鸿沟，只能模糊地描述他们想要的东西
3. 开发人员很努力去理解自己不熟悉的领域，但也只能形成模糊的认识
4. 开发人员之间相互翻译，开发和领域专家之间相互翻译，造成概念上的混淆
5. 同一个人讲话和写东西不是一个语言

信息流上存在瓶颈，不准确，沟通词不达意。间接的沟通，导致分裂的形成，导致软件各部分不能浑然一体。

如果语言支离破碎，项目必然遭遇严重问题