59 | 少谈点框架，多谈点业务

“框架，提现的是需求泛化的能力”。 体现需求泛化的能力，就是架构可以适应需求的变化。需求的变化就是接口的变化，因为本文说了，接口代表需求。 接口代表了要做什么，需求就是一个要做什么的集合，是目的。接口是需求的流程分解，即可以体现用户地图。 程序分为算法和数据结构，业务分为接口和业务数据，业务数据是业务的沉淀，是比框架更稳定的东西，而接口是在数据之上的动作，所以位置最高。

定义了数据结构，但是不抽象数据的业务逻辑，直接让使用方操作成员变量，或者定义一堆成员变量的 get/set 接口。 这句话含义是DDD中的贫血模型了。比如我需要判断某个实体是否是合格的，需要通过a,b 字段来判断。这个实现没有定义在数据结构里，却把a,b字段通过get暴露出去，让调用方去判断了

比框架（架构图）更重要的是数据结构，比数据结构更重要的是接口。这句话不是很认同。一般业务迭代中，接口的变化是很快的。底层数据结构和框架比接口更稳定

用实现机制替代业务。这个什么理解呢？

许老师好，现在有些SaaS 企业PaaS化，请问从SaaS 向PaaS 过度的关键技术是什么呢？在系统架构上两者有什么本质区别吗？望不吝赐教。

架构到数据结构，再到接口，是一个设计到实现的过程，接口定义了业务的逻辑，数据结构定义了领域实体，对实体的业务的动作是实体对外胡接口，多个内聚的实体构成了模块，相互独立，正交的模块构成系统，类似面向对象的领域设计理念。 感觉最核心的是实体=数据结构+接口，😄

老师，不太明白您对框架的定义，等同于架构图？ 能否解释一下。 您说的框架应该不是指那些三方的开源框架吧。

数据结构是指的是表结构或者是实体吗？还是什么链表，栈，树之类的数据结构呢？

目前来看，架构设计套路有限，但业务领域无限。如何应用有限的套路做出无限的架构设计，难点应是在业务上。没有足够的业务背景积累和业务需求洞察，架构设计就会出现知易行难的窘境。但是想要架构师一步到位具有健全的业务领域知识也是不现实的。所以，横竖都不好，那么就落地灵活的设计，动态去演变，也就所谓的演进式架构。而代码变动是高成本的，所以要想办法降低成本。首先代码可读要高。接着，单模块内各层，以及模块间的耦合要低。最后，代码的实现要采用合适的设计模式，以便易于扩展。但这三点不取决于架构师，具体业务开发个人素养的影响更大。所以，感觉约往后，业务开发的个人素养要求会越高。至少领域设计（战略规划）和架构分层、设计模式（战术应用）的诉求怕是少不了的。

老师今天课程中提到了一个很关键的现状：框架绑架开发。这其实是许多程序过程中经常碰到的问题：某种框架不错大家去用，可是随着业务的复杂度和需求的复杂度的增加我们会发现被框架绑架了-实现不了，然后就开始调整需求或者实现方式。 这些年更多基于内核或者核心去改/写框架的：稍微有点特色就火了；其实我们去看本质会发现，只是降低了对某些框架的绑定能力而已，当程序中一大堆框架时其实我们就被一大堆事物绑架了。框架使用的度确实是个问题：用的越深绑架越深，故而其实都是在努力的做解绑-最小需求使用。 以上是个人的一点切身体会和薄见：一路听老师的课一路学习修正；期待老师的后续分享。