抓住业务核心,避免过度抽象_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > 抓住业务核心,避免过度抽象

抓住业务核心,避免过度抽象

 2017/7/23 5:34:09  倒骑的驴  程序员俱乐部  我要评论(0)
  • 摘要:业务背景按照惯例,先介绍一下业务背景。公司有两块比较相似的业务领域,一个是统一登录,一个是三方账户绑定。统一登录时公司自有业务渠道的登录入口,主要完成帐户登录的鉴权,包括手机号+登录密码、用户名+登录密码、短信验证码登录等。和所有网站的登录站点做的事情一样,不再赘述。三方账户绑定是指集团其他子公司之间通过身份认证+用户授权绑定实现账户互信,账户首次绑定需要双方做登录鉴权操作,绑定之后只需要第三方账户登陆,用户便可以免登陆的情况下获得我司的登录态权限。简单业务流程如下:注意
  • 标签:抽象

业务背景

按照惯例,先介绍一下业务背景。

公司有两块比较相似的业务领域,一个是统一登录,一个是三方账户绑定。

统一登录时公司自有业务渠道的登录入口,主要完成帐户登录的鉴权,包括手机号+登录密码、用户名+登录密码、短信验证码登录等。和所有网站的登录站点做的事情一样,不再赘述。

三方账户绑定是指集团其他子公司之间通过身份认证+用户授权绑定实现账户互信,账户首次绑定需要双方做登录鉴权操作,绑定之后只需要第三方账户登陆,用户便可以免登陆的情况下获得我司的登录态权限。简单业务流程如下:

 

注意:三方帐户绑定服务端是在三方帐户服务 thirdaccount 组件,登录鉴权场景是在统一登录服务 loginservice 组件。前端对应的静态资源也是分开在两个组件上。

问题描述

可以看到‘三方帐户绑定’的过程中,需要做我司帐户登录鉴权,这里的登录鉴权和‘统一登录’场景一样,可以有多种登录鉴权方式。这两个业务场景对于前端来说,页面都类似,流程也一样。

前端同事遇到了疼点:两个相似度极大的模块静态资源存在两份,每次加入新的登录鉴权方式,都需要两边维护,成本较高,因此,前端便希望抽象出统一的页面和前端业务逻辑,配套的前端希望服务端统一提供一个登录接口,这个接口既可以做纯粹的登录,也可以做‘三方帐户绑定’,只需要多送两个:三方业务渠道(channel)、三方帐户标识(thirdAccountNo),服务端的接口判定thirdAccountNo是否有值来决定,在登录鉴权完成后,是否需要做三方帐户绑定。流程简述如下:

 

但是服务端不赞成这样做,服务端认为这样会造成两个独立的业务领域耦合在一起,弊大于利。矛盾在此。

 各抒己见

客户端的观点

1、‘三方帐户绑定’和‘登录鉴权’场景的目标都是为了生成我司帐户登录态,里面的大部分业务逻辑是公共的,除去‘帐户绑定’这一步。因此,可以统一纳入到统一登录服务这个入口完成。

2、从开发和维护成本来讲,后续增加新的登录鉴权方式,只需要更改一套代码就ok了,不需要既更改 thirdaccount 和 loginservice。

服务端的观点

1、从纯粹的业务领域来讲,登录和三方帐户绑定是两个不同的业务领域,不应当将‘三方帐户绑定’纳入到‘登录鉴权’的业务领域。虽然他们最终都得到共同结果——生成我司帐户登录态。

2、从业务安全角度上来讲,不同安全级别的业务应当做隔离。三方帐户绑定这种‘授信’式的鉴权方式安全性相对并不高,很大程度上依赖于合作伙伴的安全性,而登录鉴权作为我司自有的登录入口,我们可以做很多安全加固:图片验证码、帐户锁定逻辑、风控接入等,不同安全级别的业务做隔离的好处在于,出现紧急事件时,我们可以将风险隔离在较小的范围内,这样紧急处理起来牵挂更少。

3、从业务核心维度来看,‘登录并绑定’中的‘帐户绑定’才是我们的核心业务,‘登录鉴权’只是这个核心业务目标中的一个环节,所以‘三方帐户绑定’场景就应当放在 thirdaccount 组件里。

4、从组件依赖上来看,关键路径服务组件 loginservice 不应当反向依赖于非关键路径服务组件 thirdaccount。在反向依赖的情况下,一旦 thirdaccount 组件出现故障,很可能拖累道 loginservice,进而影响到自有渠道的帐户登录。

5、从开发成本角度来看,thirdaccount并不会增加太多的开发和维护工作。在 thirdaccount 提供的‘登录并绑定’ 服务契约兼容‘登录鉴权’服务契约的前提下,thirdaccount只需要在需要鉴权的时候透传请求给loginservice即可,而且如果契约设计良好,及时增加新的登录鉴权方式,也不需要更改thirdaccount。

达成一致

服务端的3、4点理由存在相当的合理性,最终前后端达成一致,服务端不应当将 ‘三方帐户绑定’ 服务合并至 ‘登录鉴权’ 服务,为了配合前端的页面抽象,服务端在 thirdaccount 提供一个新的通用 ‘登录并绑定’ 服务给前端,该服务和现有的 ‘登录鉴权’ 服务契约兼容,前端自行根据是否存在 ‘三方帐户标识(thirdAccountNo)’ 来决定是调用 loginservice 的登录服务,还是调用thirdaccount的  ‘登录并绑定’ 服务, 简要流程和图一保持不变。

心得

1、分清讨论case的核心点,不要被细枝末节干扰。搞清楚业务case的业务目标是什么?这个目标就是你的业务核心点,就像 ‘登录并绑定’  case,既有 ‘登录’ 又有 ‘绑定’,但是 ‘绑定’  才是核心点,‘登录’ 是为了 ‘绑定’ 而做的,‘绑定’ 才是我们的业务目标;

2、关键路径服务尽量少依赖其他服务,尤其是非关键路径服务。例如本例中的 loginservice 不应当依赖于 thirdaccount;

3、不要为了眼前的便利做过度的抽象,后续可能的业务变化会让过度抽象成为镣铐。比如如果这次将 ‘三方帐户绑定’ 并入到 ‘登录鉴权’ 服务中,现在看来一个服务搞定了,但是假如后续有一个三方渠道不在 thirdaccount  服务组件中处理,那么loginservice就需要再次依赖其他业务组件,需要更改抽象出来的公共服务,最后适得其反。

发表评论
用户名: 匿名