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

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

(资料图片)

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

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

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

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

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

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

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

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

更多精彩，请看下回分解-- 前端如何主导ddd架构落地（下）