关于DDD的前期调研和设想
对于架构设计，我们先要理解软件的本质，有扎实的基础，才能真正落地，同时借鉴服务端、操作系统等经验，事半功倍。
如果我看得更远一点的话，是因为我站在巨人的肩膀上。 ———— 牛顿
一. 当前WEB前端所要去应对的场景是什么?
可以总结为三大类:
- 业务系统
- 通用应用
- 工具类的应用
⠀这三类可以统称为站点,或者是应用,最早的叫法是软件,我们可以从不同的角度去叫它,但表达的都是一个意思.
- 业务系统,比如说银行的客户管理系统,物流管理系统之类的,现在整个近十年趋势,都是从以前的CS架构转变成BS架构,所以大部分这种系统,都是以Web形式呈现的. 和通用应用不同的地方在于,业务系统更多的会用Web技术去做;
- 而通用应用一般不仅是web形式,安卓,ios各种设备都需要有
- 工具类的应用是指可以提供生产力的环境,比如你可以在上面做设计,快速获得各类报表;当下比较火的工具类应用类似Figma,百度地图
⠀通过以上场景总结, 前端DDD更多地适合用于业务系统这类场景.
二. 关于目前主流前端框架的缺陷
不知道你们有没有思考过这种问题: 特别是国内,用vue的同学非常的多.如果用vue的应用来开发业务系统,你会发现,当你写到第二年的时候,你就写不动了.因为很多用vue去做开发的应用,带有一种短频快; 或者是说,对开发者来讲,你进入这个项目待的时间不会特别长;当随着业务扩增和时间发展,会感觉代码非常混乱,在开发的时候,会在不同的文件,或者在各种组件上进行修改,那就会造成一个问题,就是开发者很难感知到我这个业务数据的变动,究竟是在什么时候触发的,除非很熟悉整个业务页面逻辑和代码结构,否则很难去维护.
如果你是在做业务系统的程序员,你可能就要思考: 难道我只需要解决好数据驱动界面的问题,我就可以把业务写好了吗?
主流框架便捷开发带来的坏处
很多时候,我们会将视图层的逻辑和业务层的逻辑杂糅在一起(比如说按钮的显隐逻辑写template里),你在阅读代码的时候,就会发现是在视图层面和业务逻辑层频繁跳跃,你需要去不停的切换你思考的场景.这往往就会给前端开发对于整个业务的理解带来更大的成本;或者说在重构或者升级框架时,还依旧带着这种思路去做,那很大概率会重蹈覆辙.
其实vue和react的框架应用,它们更多的是站在我要去解决的是前端视图层面上的东西,解决基于dom元素如何在数据驱动模式下去进行自动更新.但是在react或者vue的生态里,它们没有提供一个完美的方案去解决业务要怎么结合框架去写好代码的问题. 所以它们只是视图层面的框架,跟真正的软件架构体系还有一定的距离.
前端在业务领域内还没有形成一定的规范
如果你知道C#,你应该听过C#很好去做前后端同构,你可以理解为一份代码可以同时放在前后端运行.因为在开发的时候,一些特定的东西是按照特定的模式去相互共享的,包括一些业务上面的计算,比如前后端数值要保持一致、流程的判断.其实用的都是同一份代码,这样可以保证你在前端做的业务数据逻辑计算可以和后端保持一致.
在传统或者说CS时期的软件架构体系下,工程师们要考虑业务对象的建模,业务流程控制,到了WEB应用的年代,前端的技术发展最早是不如后端技术的,比如说后端像JAVA,会有像spring这种大统一的主流框架,但前端是没有这种比较强统一的范式.所以虽然人们形容前端是百花齐放,但很多技术都是去探索解决眼前的问题,还没有更广阔的形成把握业务的范式.
那如何解决这些问题呢?这时候可以用DDD架构的思路来解决.
三. 什么是DDD架构
DDD(Domain-Driven Design),domain这里是指领域的意思,是Eric Evans在2004年通过《Domain-Driven Design: Tackling Complexity in the Heart of Software》总结提出的一整套概念和方法论.以我个人薄弱的见解,DDD是从实际业务出发，站在解决领域问题的角度去思考和设计系统的方法论.它包含了两个方面的内容：
- 沟通方法论
- 研发方法论
沟通方法论是讲DDD是站在研发人员的角度去告诉开发者怎么去和业务方和需求方进行沟通.比如像Retail团队,在当业务方(FPM)向我们提出一个需求时,其实背后是有一个需求方(BPM)去告诉FPM他们的诉求,FPM会和需求方去接触和了解这个诉求本质是因为什么东西变化而引起的,然后再根据自己的经验总结成能够呈现在我们系统上具体的一个功能.
如果当开发者需要和需求方去沟通的时候,还是依旧站在技术的角度上(比如字段,事件)去进行,那这时候这种交流就会是很冲突的;或者说需求方不停和你说一些专业的业务词汇,如果没有很详细的解释这些词在当下的业务下的含义,作为开发者也是很难去领悟到需求方的动机.所以Eric在书里提供了一个方法论,我们可以基于一个统一语言去做沟通. 这个统一语言可以让技术人员和领域专家坐在一起构建出对应业务的领域模型，必须摒弃他们各自在自己工作范围内的狭义概念，大家找到一种相互都可以理解的概念表达方式，来最终确认各自提出的问题和回答对方都能准确理解.
我们可以使用***UML(用图形的方式来描绘各种研发场景的对应的对象和关系)***来作为统一语言进行构建领域模型.
四. 前端要关注的范畴，应该比后端还大一些
作为一名业务系统的前端开发,需要去关注这几个方面的事情:
- 业务模型(页面展示以及流程流转的条件控制等)
- 数据服务
- UI交互组件体系
⠀前端开发注定不可能只关注业务模型，在前端，特别是web领域，除业务之外关注由后端吐出的数据和界面交互是一件必须的事。甚至有这样一种情况，产品文档中指出，“用户点击该按钮时，需要弹出二次确认窗口，点击确认后该签署流转为已完成”。在这个描述中，用户点击按钮弹出确认对话框，是否属于业务逻辑呢？从传统后端的角度，当然不属于，但是，如果去掉这个交互逻辑，能否完整表达这一业务过程呢？这是一个值得思考的问题，前端如果要实施DDD，不可能照搬后端的实践。前端无法脱离交互去谈业务模型,所以说,前端要关注的范畴,应该比后端还大一些。