前端如何主导ddd架构落地(上)

·  阅读 1371

这是一个兼具技术和剧情的故事。

首先,我其实是一个全栈

我当初给我司投简历的时候,其实是想做前端经理的。面试官看着简历:做过四年的.net,接着就一直做前端开发了,典型的全栈嘛,所以,做技术经理(公司后端是java)似乎也没啥毛病。然后,我就成了一个挂着技术经理这张皮的前端经理。在非互联网公司,做一个技术经理真的要求不高,你只需要会点前后端,有过实际管理经验就能上了。在小公司,业务实现只需要在前端展示页面内容,一般就是一个大屏加上业务系统,就完了。对后端的要求就更低了,只要能查到我要的数据就行,那基本上普通的三层架构就能解决问题,最多就是在接口调用那里加一个线程池来缓解一下不到100个的并发压力。

我之所以说我是个假技术经理,是因为项目来了,我除了在前期进行前后端任务分解、计划编写之后,后面基本上不再过问后端的开发细节了。我要么就是跟踪进度,要么就是搞搞前端疑难杂症。

很显然,在大公司里,我这个技术经理是不称职的,后端的代码好坏只能看程序员的人品,直到ddd架构需要落地的事来了,事情有了“转机”。。

由于公司在上云项目,后端服务全部微服务化,然后必须按照ddd架构进行后端改造。当时,我手上就有一个业务线正在上云,上级部门检查我们的后端不符合ddd要求,然后输出了问题文档,比如耦合严重、sql过于复杂等等此类问题,做为“称职”的技术经理,我当然要把问题抛出来,让后端去修改了。当时,我估摸着改10天应该差不多了吧! 结果整整3个月过去了,后端的代码检查仍然不通过,这才有了标题说的这个故事:前端如何主导ddd架构!

为什么要用ddd

ddd中文名叫领域驱动设计,英文名叫Domain-DrivenDesign。在中台遍地开花的日子,ddd就像那道光,指引着中台的设计和落地。像阿里、腾讯等很多大公司都有完整成熟的中台产品,比较有代表性的有:阿里云数据中台、腾讯技术中台及字节的直播中台等。中台的落地过程中,微服务的设计与拆分是一个最大的痛点。微服务优点很明显,缺点也很明显,如果设计的不好,几个微服务之间相互勾连,我完成一件事可能要启动多个微服务,才能保证业务实现。这明显与微服务“高内聚低耦合”的设计初心相违背。ddd的就是基于类似这样的背景而产生的一种设计思想。

以我的理解,ddd就是要求对系统的业务模型进行拆分,然后基于此模型映射到微服务代码模型。在代码模型中,分为四层架构:基础层、领域层、应用层及用户接口层。这里面最关键的就是领域层,所谓领域,顾名思义,在一个领域内,我可以尽情玩耍,能满足我的各种需求就足够了。更复杂的需求,就在应用层里进行编排实现就行,然后在接口层对外暴露接口。基础层主要是包含一些通用技术、数据库服务及配置资源服务等内容。ddd的四层架构可以参考如下这张图:

image.png 本文对ddd不做深入分析,作为一个假技术经理,直到后端的代码在三个月之后仍然不能通过规范检查时,我实际上才真正明白,这个项目必须严格按照ddd架构落地,我这才去翻阅了一些资料。简单说吧,上面就是我掌握的关于ddd的所有内容。我基本就是靠着这三板斧把这个事给办了。

为什么是前端指导ddd架构

这一段就是后端开发看了会流泪的情节了。我曾对我上司说过,给我一个月,我能成为一个很好的java。他的回复是,如果是我,我会在准备得差不多了才会提出来。我理解他的意思,毕竟公司对人员是有定位的,你一个前端经理,天天不研究前端问题,摸鱼搞后端,成何体统?问题是技术本身并没有难度,但是有时间成本,如果你想从前端转后端,第一步是得准备一个环境吧。单单是这一步,就能让很多开发望而却步。其实在程序员这个行当里久了,你就会发现,很多牛逼的人,其实并没有强大到你追不上的地步,他其实就是行动力强了一点点而已。

是的,前面我已经提到,在我决定来搞明白什么是ddd时,我这个项目的两个后端,两个java开发,搞ddd已经搞了三个多月了。因为他们已经陷入了如何拆分复杂sql的怪圈之中不能自拔。现在,轮到前端来主导ddd架构了。。(未完待续)

本文正在参加「金石计划 . 瓜分6万现金大奖」

更多精彩,[请看下回分解](前端如何主导ddd架构落地(下) #掘金文章# juejin.cn/post/717025…)

  • 参考资料:极客时间《DDD实战课》
收藏成功!
已添加到「」, 点击更改