扩展性
什么是扩展性
扩展性，从狭义的角度去说，就是程序设计的灵活性,是程序可插拔、组件可重用设计，核心其实是一个程序架构的灵活性。体现的是一个程序员的业务视野，技术积累。
注意：架构的扩展性要求绝大部分情况下并不会直接导致编码量的陡增，就像埋下了伏笔
举例
设计一个会员卡系统，促进用户活跃，提高订单量，最终提高收入。
A方案
先做最简模型
用户绑定会员，会员拥有权益。
表设计
|表名|字段|
|--|--|--|
|用户|id、会员类型|
|会员|id、权益id列表|
|权益|id|
满足当前需求
以上设计满足了最基本的需要，但是扩展性有待商榷
B方案：
首围绕需求发散并 寻找扩展点
- 围绕卡
- 客群分析
- 用卡时间
- 获卡方式 购买|赠送
- 获卡人群
- 用卡地点
- 多卡处理
- 退卡处理
- 运营需求
- 运营收集数据：
- 会员卡产单量、产单时间
- 会员卡发放数量、发放时间
- 会员卡使用人群
- 运营人员运营可能策略
- 会员卡权益调整
- 会员卡使用范围调整[具体门店、具体区域]
- 运营收集数据：
graph LR
A[卡] -->B[客群]
A[卡] -->C[用卡时间]
A[卡] -->D[获卡方式]
A[卡] -->E[获卡人群]
A[卡] -->F[用卡地点]
A[卡] -->G[多卡可能]
A[卡] -->H[退卡可能]
graph LR
A[运营需求] -->B[运营收集数据]
A[运营需求] -->C[运营人员运营可能策略]
B[运营收集数据] -->D[会员卡产单量 产单时间]
B[运营收集数据] -->E[会员卡发放数量 发放时间]
B[运营收集数据] -->F[会员卡使用人群]
C[运营人员运营可能策略] -->G[会员卡权益调整]
C[运营人员运营可能策略]-->H[会员卡使用范围调整]
产品确认需求
与产品确认第一阶段我们认为的扩展点是否能满足他们后续的要求
综上，会员卡通过卡种则可以满足不同权益的组合，某类型会员卡设有投放条件、也有生效条件，则可以进行定点投放，而权益有多个维度如免费时长、使用地点、投放区域、封顶价格等，运营人员通过组装权益形成的会员卡的投放达到精细化运营的需求
因此进行如下程序设计抽象
只展示核心部分设计
获卡
用卡
如图所示我们将所有获取会员卡的过程抽象成预置筛选器、自定义筛选器、后置筛选器来满足后续多扩展的要求
以上简单的设计支持了运营可能多变的会员卡需求，且编码量并不会陡增，随着项目发展只需要在扩展点进行扩展即可满足业务。
我们说我们不提倡过去设计，但是不代表我们不去做适当的过度设计。 过度设计的把握是
接口能力
什么是接口能力
所谓接口能力，即和协同相对。
系统对外开放（所有对外可能性）时应当提供2种能力，即协同能力和接口能力。两者相辅相成。
接口能力：提供对外服务时，以必要的、便捷的，包括文档、平台、少量的人力投入（一般为客服）等形式提供给外部系统接入的接入能力。
最常见的如消息服务供应商提供了短信息服务。
协同能力：提供对外服务时，以必要的人力投入（一般为开发人员）配合接入本系统的能力
对比协同和接口能力，显而易见的接口能力才是我们崇尚和追求的目标
如何做好接口能力建设
剖析自身服务提供的能力类型，从扩展点看接口能力
假如你提供的消息推送系统，提供的服务是根据用户传送的内容进行推送到端的服务
那么你的扩展点可以是：
- 用户->多种类用户
- 端->多端
如果你开发的系统架构天然具备这些扩展点那么恭喜你，你只需要简单提供接入文档便可以提供接入能力
从设想到适当抽象
所有的抽象都是从设想开始，在设想中，我们通过质疑、猜测、发散思维对业务的可能性、使用技术的可能性进行深入分析。
比如做一套用户登录系统，我们了解到系统的需求是为某一类用户提供登录并保持会话的服务
那么我们可以猜测 这类用户可以通过手机号码、社交账号、注册登录、扫码登录等来登录
这些方式其实很笼统，我们可以进行整理
手机号码是一个用户的标识、而社交账号是一类账号、注册登录也是一类账号、扫码登录是登录的形式，这些不一致的概念混杂在一起我们不好分析，所以我们做以下的归类和抽象
我们从登录开始发散到如下结构
graph LR
A[自注册账号登录]-->B[登录账号]
D[XX账号登录]-->B[登录账号]
E[SNS社交账号]-->B[登录账号]
B[登录账号]-->C[账号密码验证]
C[账号密码验证]-->F[会话保持]
G[登录形式]-->C[账号密码验证]
H[扫码登录]-->G[登录形式]
S[SNS快捷登录]-->G[登录形式]
P[账号]-->G[登录形式]
因此我们已经开始设想了，这个时候我们架构已经清晰。但是这个架构中的所有组成成员是否都需要？我们要进行第二个阶段剪枝处理。
剪枝来源于我们的产品需求和后续产品设想（因此一个好的产品经理很重要）
我们需要去询问产品经理刚刚的设想哪些是可能的，这个时候需要一个优秀的产品经理。
根据与产品经理的反复确认，我们明白了往我们架构里填充的实际内容是什么，比如
graph LR
A[自注册账号登录]-->B[登录账号]
D[XX账号登录]-->B[登录账号]
B[登录账号]-->C[账号密码验证]
G[登录形式]-->C[账号密码验证]
H[扫码登录]-->G[登录形式]
P[账号]-->G[登录形式]
C[账号密码验证]-->I[token会话保持]
good luck man！