解决方案编排架构

第一阶段中台底层框架的实现实际上是解决了中台协作问题，研发效率问题。业务方根据中台制定好的流程及扩展点实现各业务方不同的业务逻辑。所以业务方各自实现定制逻辑是在特定场景、流程中使用。是语义明确且有状态的一系列服务合集。

基于流程的扩展开发模式.png

我们不妨再遐想一下第二阶段，当这个模式进行了一段时间后，突然业务A觉得他们实现的某个功能可以通用，或者业务方B觉得业务方A实现的服务他们想在自己的流程里面使用。从研发的角度来看那必定是个很开心的事，研发骨子里都会带有开源、分享精神，可以用一首抖音很火的歌来描述开发小哥哥心情：好high哟，顿时感觉人生已经到达了高潮。如果按这个方式普及开来，业务方的概念就会变得模糊，所有研发都可以发布各自认为可通用的服务。平台方的概念同样也会模糊掉，只会存在服务提供方以及流程制定方（或者服务使用方）。所以这就把原有的模式就颠覆掉了，从原先的平台特定的流程里面制定合适有服务变成提供通用服务支撑不同的业务流程。

基于通用服务的流程制定.png

目标

所有服务都是无状态、职责单一的服务，通过编排这些服务暴露出来的接口完成业务流程的定制，也就是codeless。

编排架构启动最佳时间节点

中台底层框架完成

开店流程初具可定制，服务还停留在为流程定制，有状态。