我想你一定听说过软件分层理论,由上而下,分而治之。
我是坚定的软件分层理论实践者。
不管是单体应用还是分布式应用,设计应用结构时,都会把应用结构按照功能纬度进行分层。
分离出基础设施层和业务模块层。
之前听过 ThoughtWorks 王健老师的直播分享。
关于分层和设计纬度,我又有了新的思路,本文分享给大家。
站在一个前台业务的视角
两个梯度级别
细化下第二级,平台应该提供一套整体的功能模块,并且提供使用建议。
哪些模块是必不可少的,并且提供调用链建议。
与之相对的是独立的模块,供调用者自行选择。
根据 DDD 领域区分比用功能区分,对于应用者来说更稳定。
按照业务的视角进行区分,不是基于功能的组合
按照业务的视角进行区分,不是基于功能的组合
从业务功能复用演化为业务模式的复用
对于使用中台服务的消费者来说,我们要推荐或者预设给出在消费者业务模式下的推荐功能模块。
记住这里是一组可以支撑业务模式的功能模块。
不需要让调用方去按需调用。
如果我们建立了一个业务中台中心,一个支持多端服务的业务中心。
除了领导的硬性支持,如何让服务的使用方愿意用,并且放心用?
第三点和前边基于业务的模型是一个含义
预设下图中的云服务对外提供服务
标准化服务组件
不管是账户结构还是业务流程,实际对外提供的是一种业务模式,对于接入方都是对接成本。
如果要对方乐于接入,并且持续完善,要做到接入成本低于接入体验。
功能要稳定好用,还得有服务意识。
之前业务方因为一个功能找到我, PC 页面的选择时间范围的功能不好用。
日期时间选择组件
我说不应该啊,我们开发使用的是最流行的 B 端业务的时间控件。
时分秒都可以用鼠标的滚轮,得到的回答如下
公司鼠标都换了好几波了,哪里来的滚轮?
使用方需求和供给方的实现没有对上号,这才是问题的关键。
这个不算是严格意义的技术视角与业务视角,绝对是技术思维和用户思维的冲突。
我是王明明,互联网技术开发者,阅读写作实践者。
输出我的技术思想,探索个人品牌实践之路,期待认识优秀的你。
参考资料
[1]
ThoughtWorks 洞见: https://insights.thoughtworks.cn/author/wangjian/