作者回复: 因为我们也在做中台转型,包括几年前也在做容器,微服务。最初也是有很多的困惑,我文章中提的那些问题好多我们都遇到过。然后到处找方法,但是没有现成的方法。建设过程中也有很多的思考,然后发现结合DDD的一些设计思想,可以解决这些问题,包括领域建模,分层的设计思想等等。除了中台,还有一些前端的设计思想,几个组合在一起,就是一个比较全面的中台解决方案了。
作者回复: 就是各做各的意思。
作者回复: 这里的前中后台主要还是偏重于业务应用的纬度。研发还有专门的研发中台。
作者回复: 可以的。中台是企业级,是一种战略高度。
只做项目的话,可以从领域建模开始看。
作者回复: 不是这个意思。就是将少量人用到的管理类的业务流程,从核心主流程中拿掉。单独给这批人一个入口操作。这样互联网和传统核心的应用差异就很小了,流程和界面就可以统一了。
作者回复: 有这个技术能力的话,尽量将所有的数据沉淀到一个数据中台,主要是考虑以后数据之间的关联分析。对于一些时效性要求高的,也可以分主题来存储,主要是支持在线业务。有些数据不需要太高的时效性,按照时序存储就可以了,然后建立数据模型进行处理,并对外提供服务。
作者回复: 是这样的。中台要站着企业级的角度,将企业业务作为一个整体,考虑流程的融合和复用。
作者回复: 是的。主要还是能力复用的角度考虑。
作者回复: 咱们可以多保持交流和沟通。
作者回复: 它们是不同纬度的东西,中台建设要站着企业高度。
作者回复: 可以这么理解,但是这个阶段只是平台。上升到中台还需要看看这个平台提供的是不是企业级的解决方案,这个也是阿里的第二个阶段,从平台到中台的过程。
作者回复: 谢谢鼓励!赞一个!
作者回复: 与中台关联度高的话就放中台里,不高的话可以与渠道应用在一起。
作者回复: 现在都是前后端分离模式,前端应用和业务逻辑会分开部署。
中台你可以理解为原来三层架构的业务逻辑层,不过用DDD做的业务逻辑层会更加清晰,会专门针对不同前端应用和渠道做一些通用性设计,也就是说要做业务模型设计。而前台呢就是面向用户的销售、展业等原来的前端应用。
后台你可以理解为面向管理的应用。基础能力平台也比较多呢,要分情况考虑。
作者回复: 不是这样的。你说的是API网关的职能。
业务中台是业务概念,微服务是系统实现。一个业务中台可能由多个微服务实现。
作者回复: 文章里有哈,仔细找找。
作者回复: 基本差不多。
作者回复: 是这样的
作者回复: 不是这样的。
你可以查阅一下中台相关的资料。中台是领域的概念,偏向业务多一些。在中台的领域中,可以领域建模,根据领域模型进一步分解为多个微服务,多个微服务共同实现中台的业务逻辑。