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