DDD实战课
欧创新
人保高级架构师
立即订阅
4906 人已学习
课程目录
已完结 23 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 学好了DDD,你能做什么?
免费
基础篇 (5讲)
01 | 领域驱动设计:微服务设计为什么要选择DDD?
02 | 领域、子域、核心域、通用域和支撑域:傻傻分不清?
03 | 限界上下文:定义领域边界的利器
04 | 实体和值对象:从领域模型的基础单元看系统设计
05 | 聚合和聚合根:怎样设计聚合?
进阶篇 (6讲)
06 | 领域事件:解耦微服务的关键
07 | DDD分层架构:有效降低层与层之间的依赖
08 | 微服务架构模型:几种常见模型的对比和分析
09 | 中台:数字转型后到底应该共享什么?
10 | DDD、中台和微服务:它们是如何协作的?
答疑:有关3个典型问题的讲解
实战篇 (10讲)
11 | DDD实践:如何用DDD重构中台业务模型?
12 | 领域建模:如何用事件风暴构建领域模型?
13 | 代码模型(上):如何使用DDD设计微服务代码模型?
14 | 代码模型(下):如何保证领域模型与代码模型的一致性?
15 | 边界:微服务的各种边界在架构演进中的作用?
16 | 视图:如何实现服务和数据在微服务各层的协作?
17 | 从后端到前端:微服务后,前端如何设计?
18 | 知识点串讲:基于DDD的微服务设计实例
19 | 总结(一):微服务设计和拆分要坚持哪些原则?
20 | 总结(二):分布式架构关键设计10问
结束语 (1讲)
结束语 | 所谓高手,就是跨过坑和大海!
DDD实战课
登录|注册

17 | 从后端到前端:微服务后,前端如何设计?

欧创新 2019-11-22
你好,我是欧创新。
微服务架构通常采用前后端分离的设计方式。作为企业级的中台,在完成单体应用拆分和微服务建设后,前端项目团队会同时面对多个中台微服务项目团队,这时候的前端人员就犹如维修电工一样了。
面对如此多的微服务暴露出来的 API 服务,如何进行正确的连接和拼装,才能保证不出错?这显然不是一件很容易的事情。而当服务出现变更时,又如何通知所有受影响的项目团队,这里面的沟通成本相信也不小。
相应的,要从一定程度上解决上述问题,我们是不是可以考虑先有效降低前端集成的复杂度呢?先做到前端聚合,后端解耦——这是一个很有意思的话题。今天我们就一起来聊聊微前端(Micro Frontend)的设计思想,探讨一下中台微服务后,前后端的设计和集成方式。

单体前端的困境

传统企业在完成中台转型后,虽然后台的业务完成了微服务架构的升级,但前端仍然是单体模式,由一个团队创建并维护一个前端应用。随着时间推移和业务发展,前端会变得越来越臃肿,越来越难维护。而随着 5G 和移动互联技术的应用,企业业务活动将会进一步移动化和线上化。过去很多企业的做法是为不同的业务开发出独立的 APP。但很显然用户并不想装那么多的 APP!
为了提高用户体验,实现统一运营,很多企业开始缩减和整合 APP,将企业内所有的业务能力都尽量集中到一个 APP 中。试想如果仍然沿用单体前端的设计模式。前端项目团队将面对多个中台微服务团队,需要集成成千上万的 API 服务,这就需要相当高的沟通成本和技术要求。这绝对会是一场灾难。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DDD实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • 深山小书童
    整个专栏反反复复听了好几遍,慢慢理解之后,确实感觉干货满满,谢谢老师。希望专栏结束之后会有一个github的demo项目进行升华一下,专栏就完美了。

    作者回复: 谢谢你的建议。结束后,我好好准备一下哈。
    希望学完后你能成为一个具有战略高度的架构师。

    2019-11-22
    3
  • lin yu
    看着看着就学了76%了,感觉不配合没有一个完整的demo讲,感觉还是云里雾里的,每篇都是点到即止,毕竟《实现领域驱动》这本书京东59也能买到,

    作者回复: 这个专栏主要是从微服务设计和拆分角度,来讲述如何用DDD做中台和微服务设计,每一部分都有自己的设计上的思考,所以在底层代码实现上讲的不多。不是为了纯讲DDD的战术设计方法,这也是这个专栏与其它DDD不一样的地方。不知道你有没有看过实现领域驱动设计这本书没有,你可以将两者结合起来学习。

    2019-11-23
    1
  • 陈华应
    一直都把自己的思维或者视野限制在了后端以及目前工作接触到的领域,看完之后有了一个整体的认识,以及抬头多看看多想想的念头~

    作者回复: 有时候视角高一点,看到的和想到的会不一样哈。

    2019-11-22
    1
  • zj
    总结一下,微前端和中台微服务一起作为业务组件,对外提供服务!
    2019-11-24
  • 小炭
    老系统微服务改造,前端界面都是JSP Taglib的开发方式,这种前端是不是就没办法分离了,微前端是不是只能建立在单页应用技术的基础上。

    作者回复: 现在比较适合做微前端的技术也有不少,比如Vue之类的。
    微前端应该作为企业级的战略,建议建立统一的前端界面规范和技术规范,采用统一的标准。

    2019-11-23
  • 瓜瓜
    在迭代的过程中,如果出现前端主页面和微前端风格出现不一致,怎么办?

    作者回复: 需要定义统一的前端风格和规范标准。万一出现也不影响使用。

    2019-11-22
  • 张迪
    每个微前端对应一个微服务,那流程之前的切换,对于微服务数据之前 同步是不是需要非常及时?

    作者回复: 有些数据在前端就完成了交互。

    2019-11-22
  • 张迪
    微前端的前端页面需要嵌入到 前端中吗?

    作者回复: 根据业务流程动态加载到前端集成主页面。

    2019-11-22
  • Randy Liu
    前端微服务化,前端+后端构建业务服务组件,还是领域的划分与领域边界的划清。目标还是领域的自治及领域间的链接,从而达到分而治之的效果。建立在规范,一套游戏规则的基础之上,而能更好地集成与组合。前台+中台的都微化,形成一套彻底的解决机制,是很好的实现机制。
    但是这里面还是有几个待探究的疑问:
    1.集成主页面 - 与微服务的前端页面怎么集成 ?
    2.业务单元的如何独善其身,做到真正的自治需要产品需求、前端实现、中台服务实现的顶层设计与边界区分。

    作者回复: 1、现在很多的前端工具比如Vue等,有页面注册和动态加载的机制。前端主页面可以获取到微前端页面url地址后,将对应的微前端页面动态加载到集成主页面。
    2、这个确实需要顶层设计,还得有统一的技术标准和开发规范。尤其对于通用能力的复用,还有主页面内不同微前端之间的数据共享。不过现在很多的前端工具都提供这些能力了。

    2019-11-22
  • 被秒
    对于微前端一直有些困惑,到底是独立页面,还是独立组件。独立页面就是一下放弃了SPA的各种优点,一下回到几年前。 而如果用组件,那其实又增加了开发的复杂度,而且版本发布时候又会有更多的兼容风险。 前端的变更明显比后端要频繁的多,究竟最佳实践是什么。

    作者回复: 确实会有这两种选择,独立页面 OR 独立组件
    独立页面的话,这种方案通过路由、Iframe都可以实现不同微前端应用的组合。
    独立组件的话,这种方案可采用组件化的方式构建应用,开发成本较高,配合lazyload可实现组件的按需加载。通常用这种方式需要在开发时保持独立开发,但是最终需将各组件或应用进行集成合并。
    两者各有优劣:
    前者相对实现起来比较简单,而且也可保持前端多技术栈,即通过不同的前端框架来实现。
    后者实现会有额外成本,如针对工程的合并集成。但是相比前者在依赖采用同一套,会减少很多开销。
    具体如何选择,还需依据项目实际情况来看。

    2019-11-22
收起评论
10
返回
顶部