为什么你需要学习业务建模

业务建模首先是一个定义问题的方法，其次才是解决问题的方法。

该怎么有效定义问题呢？

想要有效定义问题，就要从业务出发，首先尝试在业务中寻找简化问题的可能性，然后在技术中寻找对应的解决方案。业务建模就是这样一个过程。明确业务中的关键问题，使用易于实现的模型将业务问题表达出来。
业务建模真正的难点有两个：

  1. 清晰地定义业务问题，并让所有干系人都接受你对业务问题的定义；
  2. 在特定架构的约束下，将模型实现出来。

不要太在意获得模型是否完美，是否在概念上足够抽象，是否使用了模式，等等。反而，我们更应该关注该如何围绕模型，建立有效的沟通与反馈机制。也就是说，该怎么将模型中蕴含的逻辑讲给别人听。并且还要让别人能听懂，能给出反馈。
image.png

旧约：“前云时代”的领域驱动设计

催化剂法 建模

角色 - 目标 - 实体法 建模

事件风暴 建模

四色法 建模

新约：“云时代”的业务建模

8X Flow 建模法

用于解决以微服务、分布式事务为主导的架构风格中的业务建模问题。这个方法同样可以用于构建中台系统，也是我司目前用于中台建模的主要方法。

魔球服务建模法

用于 SaaS 化业务建模，它是一种从运营角度出发，构造 SaaS 化服务的方法。

领域驱动设计到底在讲什么？

image.png

领域模型对于业务系统是更好的选择

模型在领域驱动设计中，其实主要有三个用途：

  1. 通过模型反映软件实现（Implementation）的结构；
  2. 以模型为基础形成团队的统一语言（Ubiquitous Language）；
  3. 把模型作为精粹的知识，以用于传递。

这样做的好处是显而易见的：

  1. 理解了模型，你就会大致理解代码的结构；
  2. 在讨论需求的时候，研发人员可以很容易明白需要改动的代码，并对风险与进度有更好的评估；

  3. 模型比代码更简洁，毕竟模型是抽象出来的，因而有更低的传递成本。

    知识消化

    关联模型与软件实现

    模型关联的实现方法，也就是被称作“富含知识的模型（Knowledge Rich Model）”

    基于模型提取统一语言

    领域驱动设计中的统一语言，特指根据领域模型构造的共同语言
    统一语言可以包含以下内容：

  4. 源自领域模型的概念与逻辑

  5. 界限上下文（Bounded Context）
  6. 系统隐喻
  7. 职责的分层

  8. 模式（patterns）与惯用法

    开发富含知识的模型

    提炼知识的循环大致是这样一个流程：

  9. 首先，通过统一语言讨论需求

  10. 而后，发现模型中的缺失或者不恰当的概念，然后精炼模型，以反映业务的实际情况
  11. 接着，对模型的修改会引发统一语言的改变，再以试验和头脑风暴的态度，使用新的语言以验证模型的准确。

    精炼模型

    头脑风暴与试验。

    同意语言是必要的吗？

    image.png

    我们要怎么理解领域驱动设计？

    简单总结一下，首先是权利与义务的对等构成了协同的基础。技术方通过统一语言获得了定义业务的权利，但是同时也必须承担在提炼知识的循环中接受业务影响实现的义务；而业务方呢，通过提炼知识的循环获得了影响软件实现的权利，但是同样，也有接受技术方通过统一语言定义的业务概念的义务。

领域驱动设计是迭代改进试错法。这是一种保底可行，但可能效率不高的建模方法

对于领域驱动设计和知识消化，多年来行业也多有诟病，主要集中在这么三点：

  1. 第一，随着 ORM 的流行，关联模型与实现慢慢成为行业内的默认做法，于是大家的关注点也逐步过渡到怎样才能更好地建模。但是迭代试错效率真的不高，特别是技术方与业务方没有足够的信任的时候，可能就迭代不起来了。
  2. 第二，统一语言虽然赋能了技术侧，使其有了话语权，但是也给了技术人员不去学习业务的借口。比如技术可以硬拗很多奇怪的东西给业务方，以此来逃避对业务的真正学习。
  3. 第三，统一语言并不容易实现，技术人员不习惯去驱动这样的改变。而一旦无法形成真的统一语言，提炼知识的循环也就无法进行了，那么整个方法也就失败了。