【云驻共创】DDD时代浪潮的大背景下,前端可以搭上这趟快车吗?

XiaoLin_Java 发表于 2022/01/26 17:08:06 2022/01/26
【摘要】 什么是DDD相信最近不少小伙伴都听过DDD这三个字,他现在变成了编程圈子里面的热词,大厂都纷纷拥抱DDD的怀抱了,那么我们不仅要问什么是DDD?他真的有那么厉害吗?DDD的学名叫领域启动设计,他的名字听起来有点高大上,接下来我将用最最最浅显的语句来解释。其实DDD很简单,小王去入职的时候,有两家公司,A公司是里面就三个人,一个老板,一个会技术会销售会设计的研发,一个会管理会财务会招聘的财务...

什么是DDD

相信最近不少小伙伴都听过DDD这三个字,他现在变成了编程圈子里面的热词,大厂都纷纷拥抱DDD的怀抱了,那么我们不仅要问什么是DDD?他真的有那么厉害吗?DDD的学名叫领域启动设计,他的名字听起来有点高大上,接下来我将用最最最浅显的语句来解释。

其实DDD很简单,小王去入职的时候,有两家公司,A公司是里面就三个人,一个老板,一个会技术会销售会设计的研发,一个会管理会财务会招聘的财务,小王入职了以后需要全方面去学习公司的各方面业务。B公司是有分研发部、财务部、市场部等若干部门,小王入职了只需干好他本职的工作——研发即可,你觉得小王会去哪家公司?DDD的本质思想也是如此,老板只需要招专业的人干专业的事情,开发系统的同学在设计的时候,会把这个系统分为若干不同的层,每个层写每个层的事情,闻道有先后,术业有专攻说的就是这个理。

image-20220125093738920

近几年来,随着大数据的爆发,各个公司的业务系统不断扩大,微服务架构成为了设计的主流,业务中台也逐渐成为了大厂的标配,虽然现在IT的从业者人人都了解微服务架构,但是能设计好微服务的人并不多,设计微服务最难的是如何拆分,怎么拆分,为什么要拆分成这几个服务?这些服务之间是怎么判断的?当一个设计来临的时候,我们该放在哪个服务区实现呢?这些一连串问题下来,估计会难倒很多的架构师。微服务的设计有没有一套比较完善和成熟的方法论呢?其实这就是DDD设计的初衷。

DDD为什么适合微服务

DDD与微服务有一点类似,都是处理复杂领域的设计思想,DDD是一种解决复杂问题的解决过程,他体现的是术业有专攻的分而治之的一种思想,当我们遇到一个比较复杂的问题的适合,如果你有能力直接解决最好,如果能力比较弱,就将大问题分解成一个个小问题,再讲小问题一个个击破,即可解决大问题。

image-20220125102839426

DDD并不是一种架构设计,他体现的架构设计的方法论,是一种处理复杂领域的设计思想,他包括战略设计和战术射击两部分,分别从不同的视角出发,将业务的复杂度和技术的复杂度分来,从而达到将复杂领域的问题简单化,帮我们划分业务领域和边界,从而可以简单高效地实现微服务架构的设计。

战略设计是从业务的角度出发,划分边界,简历上下文,构建领域模型,而战术设计是站在程序员的角度从技术出发,重点是对领域模型的技术实现。战术设计中包含了聚合、实体、值对象、资源库、领域服务、领域事件、模块等。

image-20220125105715074

image-20220125105731536

DDD能给前端带来什么

概述

前端和后端不一样,在后端眼中,最小的粒子是类或者对象,而在前端开发者的眼中,通常都是以一个页面作为最小粒子的,我们通过类别,可以将前端的一个页面类比成后端的一个实体,一个页面上的不同标签就是类的不同属性。

前端的工作职责是面向交互,对于前端开发来说,日常主要实现的是页面的交互层面,但是在现在多端的业务场景下,设备和场景分裂很严重,我实现一个小的功能,需要在M端展示,在PC端展示,在小程序端同样展示,那么同样的逻辑代码我必须实现很多份,多端实现,如果今天产品心情不好,需要在原来的代码里面加一个魔法值,那么这小小的改动就会导致我需要发很多个版,这就是设备、场景的分裂带来的局限性。那么前端实现DDD能带来什么好处呢?

好处

随着业务的扩大,在前后端分离的项目中,前端的项目变得越来越复杂,关注的点也不再是交互层面了,更多的也偏向数据层面了也是以前简单的前端UI框架已经很难满足中大型企业的开发需求了,于是就出现了redux和vuex等偏向于业务类的框架,他们的作用也是为了管理中大型企业项目的数据管理问题,接下来我将讲解一下DDD给前端带来的好处。

首先是最直接的就是前端代码的健壮性,我们在提到代码健壮性的时候,首先想到的都是高内聚低耦合之类的套话,在业务最开始的时候不是什么大问题,但是在业务不断变化的时代,日积月累就会形成低内聚,高耦合的代码,而DDD信奉的是将业务需求最大程度的抽象,他最大程度减少我们需求变化的可能性,进而提升了业务代码的健壮性。

其次就是业务的灵活程度很高,由于DDD的设计,边界被分割的十分清晰,在很多的业务场景下,业务与技术的彻底分割,只要没有需求或者是核心业务的大变化,他的灵活性是十分高的。

前端工程容易维护也是他的优点之一,DDD不是架构设计,而是一种设计思维,由于项目的色剂是架构师、开发、测试、设计等多方协调的工作,所以在工程维护上,使用DDD思想设计的架构更不影响其他兄弟部门,更容易维护。

前端集成也会随着DDD的出现变得更简单,实现了前端模块化和拼图化的开发,进一步降低了前端集成的复杂度和成本。

DDD+中台的落地可以实现业务的开发、测试、集成、部署等全流程和各个生命周期的管理,大幅度降低了后端和前端以及测试沟通的成本,实现了版本发布周期的快速迭代,同时在版本迭代的时候不会影响其他服务的正常运行,真正做到了业务隔离和敏捷发布。

如何实现分治

前面我们说过了,DDD的核心是分而治之,将一个大BOOS分解成一个个小BOSS,然后逐个击破,那么我们如何实现分而治之呢?我们首先需要了解三个概念:

  1. 聚合根:聚合根指的是一组相关对象的合集,这一个合集作为一个整体被外界访问,聚合根有一个ID,这个ID是全局唯一的。
  2. 实体:这个实体和后端的实体是有区别的,他是有证明周期同事是有状态的,通过全局唯一ID进行区分。
  3. 值对象:值对象指的是描述事务的对象。

一句话概括就是使用聚合根来引用实体,挂载值对象,屏蔽内部的实体逻辑。

image-20220125151540441

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:cloudbbs@huaweicloud.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。