通过我们工具和平台的技术能力,使我们开发代价和门槛逐步的下降,只有让开发门槛降低,开发人员才会更多,我们创意才会增加,我们整个开发才会繁荣
开发工具的进一步发展趋势就是服务化及平台化,这样才能建立一种良性的关系,实现平台与开发者的共赢,通过平台的技术能力使软件开发的代价和门槛下降,让更多的人参与进来,哪怕没有太多的程序开发经验,每个人都能写一些编程代码,这才是软件开发应有的开放精神。
组织介绍

软件业云化、平台化、服务化发展趋势凸显
中台化建设一些基本认知:组件化、微服务、模块化区别与联系
最近两年,各个互联网公司都在进行中台化拆分建设,这里面有很多基本认识和概念
架构视角:
1.大中台,小前台
只要中台服务足够强大,新业务可以调用中台的各个公共的组件采用类似积木的方式进行快速构建。前台系统只需要投入少量的人力成本,就可以快速完成新产品的研发和上线,并根据市场反馈在做调整

2.组件化与项目微服务化
内部系统项目可以采用“组件化”思路(即微服务化)来进行子系统拆分,对内部项目的“前中台”拆分,各个子系统独立部署

3.组件化与前端
前端发展三个阶段:

1)代码耦合阶段
2)前后分离阶段:前后台工程代码单独部署
3)前端组件化阶段:具体实施:构建一套组件库,支持自定义组件,各自不同系统采用不同的组件服务,前端组件包括基础组件,业务组件,统一部署,版本控制
4.组件化优点

a) 系统解耦
b) 可复用度高
c) 利于专注具体功能点开发
d) 减少每一次改动需要全量回归测试
e) 业务积木化,降低运营成本,功能热插拔
5.组件化实施

a) 避免组件间相互应用,通过路由或总线方式处理挂载到组件总线上的业务组件,都可以实现双向通信.而通信协议和HTTP通信协议类似,即基于URL的方式进行.
b) 业务模块化是业务的横向拓展,组件化在业务上是纵向分层,可以是某一业务的完整功能集,也可以是一个单独的功能点
6.组件化的层次

a) 基础服务组件
业务上定位为最小粒度的组件:可以是一个功能点,也可以是一个完整的功能集–查看订单组件、鉴权组件
b) 业务模块组件
某一业务场景完整功能集:由基础服务组件组成、数据集–购物车、下单、会员中心
c) 系统级组件
业务场景解决方案:app购物、pc购物
工程视角:
1.工程模块化设计原则

a)越底层的模块,应该越稳定,越具有高度复用性
b) 不要让稳定模块依赖不稳定模块,减少依赖
c) 提升模块的复用度、自完备性
d) 业务模块之间尽量不要耦合
2.组件与模块的区别
输入图片说明
组件:最初的目的是代码重用,功能相对单一或者独立。在整个系统的代码层次上位于最底层,被其他代码所依赖,所以说组件化是纵向分层。
模块:最初的目的是将同一类型的代码整合在一起,所以模块的功能相对复杂,但都同属于一个业务。不同模块之间也会存在依赖关系,但大部分都是业务性的互相跳转,从地位上来说它们都是平级的(秒杀、优惠券、特权)

成就
6
Star
17.7K
Fork
成员(1)
385826 5188 1578922240 qixiaowei

搜索帮助