以我所主，为我所用

领域驱动设计

7分钟阅读

  • 背景： 软件开发的核心难度在于处理隐藏在业务知识中的复杂度，那么模型就是针对这种复杂的简化与精炼。构造专用的模型，将相关的业务流程与功能转化为模型的行为，借此避免开发和业务方的认知差异
  • 领域模型所带来的好处：
    1. 以模型反应软件实现（Implementation）的结构，这样新人只要理解了模型，就能大致理解代码的结构。
    2. 以模型为基础，形成团队的统一语言（Ubiquitous Language），方便研发在讨论需求时更容易明白需要改动的代码，从而更好的评估风险与进度。
    3. 以模型用于抽象知识，相比代码本身有着更低的传递成本。
  • 知识消化法提炼模型
    • 模型与软件实现关联：
      • 借助面向对象构造”富含知识的模型“，即”充血模型“。
      • 利用关联对象实现聚合关系。
      • 利用上下文对象完成实体对象到角色对象的扮演。
      • 利用能以供应商模式，将基础设施作为能力供应商配合其它层使用。
    • 统一语言与模型关联：
      • 统一语言的必要性：
        • 业务习惯从流程、交互、功能、规则、价值等业务维度出发去描述软件系统。而模型则偏向于在不同业务维度下，数据将会如何改变，以及如何支撑对应的计算与统计的数据维度。业务的维度被模型的抽象隐藏了，业务方无法从模型中直接感知到业务维度。我们需要一个缓冲地带：既能在模型的核心位置扮演关键角色，又能弥补视角差异。
        • 对于未提取的知识，超出了模型的表达能力。只有通过统一语言去确立。
      • 修改代码就是修改统一语言：
        • 不是因为需求变更，而是因为代码重组与重构引起的代码修改。需要借助统一语言，让业务方了解并接纳。否则就会陷入双方都看不爽的境地上。
        • 修改代码引起模型改变是不可避免的，业务能做的，仅仅是能否知晓这种改变，是否有机会验证这种改变在合理的方向上。
      • 展开模型替代统一语言：
    • 提炼知识的循环：
      • 对于技术方来说，通过统一语言获得了定义业务的权利，同时也必须承担在提炼知识的循环中接受业务影响实现的义务。
      • 对于业务方来说，提炼知识的循环赋予了他们影响软件实现的权利，同样也有接受技术方通过统一语言定义业务概念的义务。
    • 对于处理隐藏业务复杂度的优势：
      • 想要处理这种复杂度，首先需要借助统一语言打破知识壁垒，如果双方对彼此的知识域有基础的了解，那么知识传递与沟通的效率就可以变得更高。
      • 复杂的问题只有快速的反馈试错。双方参与到彼此工作中，可以在流程中给予对方反馈，而不是等到产生最终结果之后再评价。做到真正的敏捷开发
      • 业务方和技术方参与到双方的工作中，就在双方之间带来了 1 + 1 > 2 的协同效果
  • 领域驱动设计究竟是什么：
    • 不那么靠谱的迭代试错法：模型没有对错，只有能不能在需求上更好应对变化。需求是复杂多变的，没有现成答案，试吧，会试出来的。
    • 具有协同效应的工作方式：统一语言是在使用中被确立的，需要管理变革去推动。头脑风暴与试验简化了变革，但是没办法保证百分百的成功。
    • 较为宽泛的价值观体系：
      • 领域驱动设计是一种模型驱动的设计方法：模型应该处在核心。
      • 业务和技术围绕模型的协同。
  • 所存在的缺点：
    • 迭代试错效率不高，如果业务和技术方没有足够信任，将无法进入迭代。
    • 统一语言给了技术定义业务的权利，但是也带来了技术不学习业务的借口。
    • 技术人员不习惯驱动这样的改变。如果无法形成统一语言，就无法进入知识的循环。

关系图谱

反向链接