徐昊《如何落地业务建模》读书笔记

单体架构

业务建模难点

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

DDD

软件开发的核心难度在于处理隐藏在业务知识中的复杂度。
DDD是一种模型驱动的设计方法：通过领域模型捕捉领域知识，使用领域模型构造更易维护的软件。

知识消化

两关联一循环
两关联：模型与软件实现关联；统一语言与模型关联
一循环：提炼知识循环

与模型关联的实现方法，称为 富含知识的模型

协同效应

让业务方与技术方参与到对方的工作中，就在双方之间带来更好的协同效应（Synergy Effect)

迭代式试错建模法

DDD尝试解决的是复杂问题，没有现成答案，迭代式试错建模法是唯一可行的方式。

价值观

领域驱动设计是一种模型驱动的设计方法，模型处于核心
两关联一循环：业务和技术围绕模型的协同

关联对象

关联对象实际上是通过将隐式的概念显式化建模来解决问题。
可以作为实现聚合关系的默认方法。（很好的解决翻页的问题）

上下文过载

上下文过载，指领域模型中的某个对象会在多个上下文中发挥重要作用。
上下文过载会导致认知过载，从而导致维护困难。
实体在不同的上下文中扮演多个角色，再通过聚合关系，将不同上下文的逻辑富集于实体中，造成上下文过载。

通过角色对象分离不同上下文的逻辑。
将不同上下文的逻辑富集于不同的角色对象中
实体对象转化为角色对象，经由显式的方法调用（asXXX），实际表示了上下文切换。

角色-目标-实体法（Role-Goal-Entity)

除了能得到更纯净的领域模型，还提供一种收集需求，结构化进行领域建模与构建统一语言的流程。
在领域驱动设计中得到广泛的认可和实践。
共创过程中，存在 收集-建模-说服 3个步骤。

事件建模法（Event-Based Modeling)

通过事件捕捉系统中信息的改变，发掘触发这些改变的源头，通过这些源头找到背后参与的实体与操作。
模型侧重于数据角度，而业务维度的流程，交互，功能点，更关注行为。

领域事件：发生在领域中且值得关注的事件。领域事件通常意味着领域对象状态的改变。
判断方法：能否将这个事件当做领域逻辑的等价接口，可以起到这种等价作用的事件就是领域事件。

事件建模法是一种元方法（Meta Methodology).
（熟练之后，可以根据业务需要发明自己的方法）

命令Command：事件起因（AIC,Actor Initiated Command)
策略Policy: 策略可以触发命令，成为系统触发命令（SIC, System Initiated Command)

头脑风暴的不足，成功取决于收敛逻辑 —— 弱分析法
想要更加有效的获取领域事件，关键在收敛而不是发散。

四色建模法

从收敛逻辑出发的强分析法。

将模型实现为RESTful API

通过领域模型驱动获得API的设计。
要从数据角度，而不要从行为角度去构建API
通过URI表示领域模型，路径可以看作是对某种层次结构遍历的结果

设计API流程（角色-URI-业务场景）和“角色-目标-实体”法类似。（但 业务场景是目标，实体是URI表示的领域模型）

渐进式服务消费

渐进式服务消费，在客户端的多样性和API的稳定性之间，取得了完美的平衡。
由服务器指导的客户端侧集成（Server-side Guided client-side integration)
通过超媒体描述的增强服务，让客户端和服务器之间形成一种协商与匹配关系，就是渐进式服务消费。
HATEOAS（Hypermedia As The Engine of Application State），是最高成熟度的RESTful API
在构造资源时，缓存要当作必须考虑的特性，详加设计。
将集成与订制推向客户端，保持服务端的稳定（互联网架构的精髓）

模式

同样的解决方案与不同的问题配对，也就产生了不同的模式。
模式最难的地方在于判断当前的问题与模式要解决的是否是同一个问题。

软件工程的本质性与附属性工作

Fred Brooks将软件开发分为本质性工作(Essential Task)和附属性工作(Accidential Task)
本质工作：解决本质性困难的工作，如何从抽象性问题发展出具体概念上的解决方案。（如何理解我们要解决的问题，并选择恰当的解决方案）
附属性工作：将寻找到的解决方案，转化为电脑可执行程序的工作，这过程中碰到的困难，就是附属性困难。
本质性技能：理解问题和定义问题。（而不是 不定义问题，随意归因和迷信复用）
（
不定义问题：不问要解决什么问题，按着套路推代码
随意归因：不把问题的根源追溯到业务上，寻找到技术上要解决的问题就停止了）

迪米特法则

迪米特法则（最小可知法则）：在面向对象设计中，实体应尽可能少地与其他实体发生交互。
（互联网架构的核心在于开放性和拓展性）

云时代

弹性边界还是业务边界

弹性优先还是业务优先？
应该是弹性优先，更符合功利主义架构思路（Utilitarianism)
（如果2个上下文明显具有不同的弹性诉求，就应该拆分；如果具有一致的弹性诉求，可以不拆）

微服务划分：已弹性边界为主，业务上下文为辅。

（云平台的弹性并不总能改进响应时间，但一定可以提高吞吐量）
阿姆达尔定律（Amdahl law)：通过水平拓展产生的加速比，依赖于计算中可并行化的部分。

如何避免弹性耦合？
将同步调用改为异步。
服务与组件间的同步调用，会带来响应时间的依赖；而异步调用，能将其改变为吞吐量的依赖。

James Lewis, Martin Fowler在微服务书里提到：Synchronous calls considered harmful
云时代，异步调用和事件驱动架构风格将逐渐成为主流
Netflix提出，需要将同步调用替换为异步。
Async API Initiative: https://www.asyncapi.com/

8X Flow

业务与领域的区别？

领域表示与运营无关的问题域；业务表示与运营相关的问题域

“两关联一循环”对业务逻辑建模的效果要远远好于对领域逻辑的建模效果
业务逻辑是和某种运营方式绑定的，这个特性为 运营特定（Business Operation Specific).
领域中立（Domain Neutral)

业务逻辑：
运营特定 和 领域中立性
领域逻辑：
运营中立性 和 领域特定性

业务系统：支撑业务运营，利用领域系统赚钱/省钱的系统，叫 业务系统。

从弹性优先的角度，应该将关注业务逻辑的组件与关注领域逻辑的组件分离。

构成审计核心逻辑的凭证追溯，是四色建模的核心逻辑。
合同履约是8X Flow的核心逻辑。

权责履约是最小的业务交互，合同是最小的业务上下文。
因此，可以采用权责和合同上下文对业务进行建模。

合同上下文可以看作是两个角色间业务交互的证据聚合。
是一种业务存在的聚合关系，是一种比业务聚合更具有业务含义的包含关系。

通过Request-Confirmation表示的履约结构是一种异步结构。
这种异步不是技术上的刻意选择，而是业务的真实状态。

中台建模：寻找可复用的业务模式

业务模式实际上是一组决策模式的集合
最好的办法是从已经存在的业务模型中去提取，而不是直接建模。
需要恰当的抽象（不是不会抽象，是很容易过度抽象）

合同上下文非常适合提取宏流程：

1. 合同履约本身隐含了双方业务往来的流程
2. 合同上下文中的角色是变化点，而引入变化点的，就是业务流程的泛化

从合同出发寻找的合同流程，是业务流程的目标与模板。业务流程，是对合同流程的实现与映射。