复用
讲到这儿，相信大家一定有一个疑惑，无论是说企业级，多前台产品团队，还是讲能力沉淀，都不是什么新话题。很多企业组件化，服务化，平台化搞了好多年，那「中台」到底有哪些新的启发？
我的答案就是对于「复用」的关注被提高到了一个前所未有的高度。
虽然我们一直讲「去重复用」讲了很多年，但仔细想想，大多平台化建设会将重点放在「去重」（消除重复）上，而对于「复用」则没有足够的关注。
很多企业都号称已经建成了各种各样成熟的平台，但是我们问心自问一下，有多少平台是业务驱动的？有多少前台产品团队又是自愿将自己的产品接入到平台上的？有多少平台建设者是在真正关注前台产品团队的平台用户体验？
「去重」讲的更多是向后看，是技术驱动的；「复用」讲的更多是向前看，是业务驱动和用户驱动的。
所以「去重」与「复用」虽然经常一起出现，一起被提及，但是谈论的完全不是一件事情，目的不同，难度也不同，做到「去重」已然非常困难，关注「复用」的就更是寥寥无几，所以：
*「复用」是中台更加关注的目标；
*「可复用性」和「易复用性」是衡量中台建设好坏的重要指标；
*「业务响应力」和「业务满意度」也才是考核中台建设进度的重要标准。
而实现更好的复用，常常改进的方向有两个方面：
一方面将更高抽象（例如业务模式级别）的通用业务逻辑通过抽象后下沉到中台，这样前台就会更轻，学习成本和开发维护成本更低，越能更快的适应业务变化；缺点是，抽象级别越高，越难被复用，需要架构师对于各业务有深入的理解和非常强的抽象能力。
另一方面就是通过对于中台能力的 SaaS 化包装，减少前台团队发现中台能力和使用中台能力的阻力，甚至通过自助式（Self-Service）的方式就快速定位和使用中台能力。目前很多企业在尝试的内部 API 集市或是数据商店就是在这方面的努力和尝试。
本文转载自健荐公众号。
原文链接：https://mp.weixin.qq.com/s/4JxgeeZeVaOASXUKjwTflg
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论