一 运用领域模型

  • 理解软件的核心
  • 领域驱动建模解决什么问题?
  • 软件复杂性有哪些?
    • 目标是什么?
    • 受哪些因素的制约?
    • 领域驱动设计的方法是怎么处理的?

1. 消化知识

1.1 有效建模的要素

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

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

1.2 知识消化

传统的瀑布模型

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

模型必须是精确的

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

1.3 持续学习

怎么保持团队的高效率

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

领域驱动设计方法中,软件的参与方:

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

软件的组成:

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

1.4 知识丰富的设计

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

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

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

例如:

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

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

超卖规则的实现

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

1.5 深层模型

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

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

2. 语言的交流和使用

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

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

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

模型与代码应当紧绑定。

2.1 UBIQUITOUS LANGUAGE

困难所在:

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

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

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