从业务功能复用演化为业务模式的复用

我想你一定听说过软件分层理论，由上而下，分而治之。

我是坚定的软件分层理论实践者。

不管是单体应用还是分布式应用，设计应用结构时，都会把应用结构按照功能纬度进行分层。

分离出基础设施层和业务模块层。

之前听过 ThoughtWorks 王健老师的直播分享。

关于分层和设计纬度，我又有了新的思路，本文分享给大家。

功能复用演化为业务模式的复用

平台如何给业务更快的支撑，回答老板的问题？

站在一个前台业务的视角

两个梯度级别

• 第一级 提供业务数据的复用
• 第二级 提供基于业务的模型，如出行行业，旅游行业

细化下第二级，平台应该提供一套整体的功能模块，并且提供使用建议。

哪些模块是必不可少的，并且提供调用链建议。

与之相对的是独立的模块，供调用者自行选择。

业务能力的管理和运营

根据 DDD 领域区分比用功能区分，对于应用者来说更稳定。

技术视角与业务视角

按照业务的视角进行区分，不是基于功能的组合

分析

按照业务的视角进行区分，不是基于功能的组合

从业务功能复用演化为业务模式的复用

对于使用中台服务的消费者来说，我们要推荐或者预设给出在消费者业务模式下的推荐功能模块。

记住这里是一组可以支撑业务模式的功能模块。

不需要让调用方去按需调用。

如果我们建立了一个业务中台中心，一个支持多端服务的业务中心。

除了领导的硬性支持，如何让服务的使用方愿意用，并且放心用？

几点建议

• 1 稳定的功能输出，消除确定性和不确定性
• 2 服务意识，把业务中台作为服务中心，调用方就是你的用户。
• 3 把调用方的使用模式从单一的功能使用 调整为业务模式的组件化使用，对你的服务产生依赖。

第三点和前边基于业务的模型是一个含义

案例

接入成本要低于接入体验

预设下图中的云服务对外提供服务

标准化服务组件

不管是账户结构还是业务流程，实际对外提供的是一种业务模式，对于接入方都是对接成本。

如果要对方乐于接入，并且持续完善，要做到接入成本低于接入体验。

功能要稳定好用，还得有服务意识。

技术思维和用户思维的冲突

之前业务方因为一个功能找到我， PC 页面的选择时间范围的功能不好用。

日期时间选择组件

我说不应该啊，我们开发使用的是最流行的 B 端业务的时间控件。

时分秒都可以用鼠标的滚轮，得到的回答如下

公司鼠标都换了好几波了，哪里来的滚轮？

使用方需求和供给方的实现没有对上号，这才是问题的关键。

这个不算是严格意义的技术视角与业务视角，绝对是技术思维和用户思维的冲突。

我是王明明，互联网技术开发者，阅读写作实践者。

输出我的技术思想，探索个人品牌实践之路，期待认识优秀的你。

参考资料

[1]

ThoughtWorks 洞见: https://insights.thoughtworks.cn/author/wangjian/