Skip to main content

ddd与移动端,桌面端,前端

DDD领域驱动设计是与后端相关联的。它的口号是复杂软件应对之道。

于是,我也时常在思考一个问题:

移动端,桌面端,前端与DDD有关联么?

领域驱动风格

在非后端,也就是移动端,桌面端或前端,我更愿意用领域驱动风格而不是领域驱动设计来形容ddd在这些技术方向的实现。

如果放在一个整体来分析,显然,无论是移动端,桌面端或前端 ,它们都可以说是后端的"前端",只是载体不同而已。浏览器我们称为前端,手机我们称为移动端,而操作系统上的原生应用程序,我们称之为桌面端。

如果我们站在后端来思考,甚至可以把这些当成一个层来看待,统称为UI层

也就是某种程度上来说,它们都只是领域驱动在后端实现中的一层而已。

那如果也用领域驱动设计来描述,我觉得不是妥当的。

它们同样是复杂的

但是,放在一个整体来考虑,显然与我们现在事实不符。

无论是移动端,桌面端或前端,说它只是UI层,又有点太小看它们了。

它们不仅仅是UI展现这么简单。

事实上,它们也承担了业务行为,比如在APP中新增一个雇员,通常的过程是:

  1. 做简单的数据检验
  2. 调用REST API,将其保存至远程服务器
  3. 如果成功,同时将其保存至本地数据库

也就是,一个业务上的行为,在它们上,不仅仅只是展现个UI这么简单,虽然业务主要是REST API来承担,但它们本身也有存储,也可能有缓存等。

同样,它们也有雇员的模型在本地。

因此,将ddd理念应用到它们上,我认为是没有问题的。


public async addMembers(contacts: Contact[]): Promise<boolean> {
const success = await Discussion.getNet().addMembers(this, contacts);
if (success) {
this.memberContacts = this.memberContacts.concat(contacts);
await Discussion.getRepository().addDiscussionMember(this, contacts);
}
return success;
}

就比如上面代码所示,新增一个群成员这个业务行为,就算是在桌面端,我们也可以把它理解为一个领域行为,放置在领域中。

更为关键,它是对整洁架构的实现

而将领域驱动风格应用到这些方面的另一个重要原因是:这同样是对整洁架构的实现。

就算是在这些方面,我们也不能对可维护性不管不顾,把所有逻辑全写在REACT或VUE中,这就如同后端以前的JSP一样,做后端的都知道,早期业务逻辑全写在JSP中,那是多么糟糕的一个时期。

同样,在前端,移动端或桌面端也是一样,遵照领域驱动风格来进行分层,并将不同的代码分散这不同的层,每一层负担并承担自己的职责。

这仍然是保证可维护性的唯一方式。

理解当然的,无论是在桌面端,移动端或前端,我们都需要可维护性。

所以,我的结论是:ddd仍然可以应用在这些方向,但一些概念,会有细微的差别。