架构师共识确认的过程

架构师需要掌握的三大技能:

别让框架捆绑业务

接口代表什么? 接口代码业务. 架构图代表什么? 架构图代表框架.

不要让框架捆绑业务.

在架构的两侧, 一边是用户需求, 一边是技术. 接口代表用户需求, 代表业务. 框架代表技术, 是我们满足需求的方法.

框架是重要的. 但不能让框架反客为主, 溢出模块边界. 在系统迭代过程中, 框架会经受变化, 以适应需求的演变过程.

抓住稳定的东西, 比追逐变化更重要.

框架的抽象能力不是一蹴而就的, 它既代表我们抽象系统的能力, 也依赖我们对领域需求的理解程度. 所以框架会随着时间而迭代, 逐步走向最理想的状态.

如何保证系统洁净, 个人建议是:

连接性的代码越少越好.

什么是连接性的代码? 就是把两个子的业务系统连接, 构成一个大业务场景的代码. 如果有大业务场景, 应该抽象出新的更大范畴的业务系统.

这样我们的焦点就始终在业务上.

每个模块都是一个业务

建议:

比架构更重要的是数据结构, 比数据结构更重要的接口.

为什么数据结构比框架更重要? 业务数据结构是架构实现机制的灵魂. 从共识的角度, 数据结构相比框架而言, 是更重要的共识.

一些架构师能够想清楚实现，但是想不清楚业务。他们用实现替代对业务系统的抽象。

用实现机制替代业务的典型案例是定义了数据结构，但是不抽象数据的业务逻辑，直接让使用方操作成员变量，或者定义一堆成员变量的 get/set 接口。

另一个例子是当我们用 ORM 框架操作数据库时，工程师非常容易犯的错误是，直接操作数据结构，而忽略定义业务接口的重要性。

此文章为3月Day22学习笔记, 内容来源于极客时间《许式伟的架构课》, 强烈推荐该课