了解你的角色:DCI、DDD 和角色的概念

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

软件工程中的所有架构方法都旨在解决类似的问题。经常使用的技术之一是 角色 的概念。

当您进行 OOP 时,您可能会使用接口(尤其是静态类型语言)。接口帮助我们思考角色——在这种情况下,这是对象所扮演的角色。

DCI架构是反对现在的面向类的思想。他们的目标是引入基于对象的完整 OOP,而不是像我们现在习惯的那样基于类。为了稍微简化一下,在 DCI 中,您应该能够在对象的基础上而不是在类级别上实现接口。

例如,如果您有一个电子书对象,您可能希望在 Shipping 上下文(通过电子邮件将其交付给客户)中暂时将其视为“数字产品”。并非所有电子书都在同一时间交付,因此所有电子书(在班级级别)都具有运输能力是没有意义的。目前,当发布数字产品很重要时,电子书就扮演了新的角色。当它在另一个上下文中使用时(在目录中列出?)它没有作用 - 它没有一些方法。

这是 DCI 使用角色的概念方式。

现在,什么是 DDD 方式?

在 DDD 中,我们使用 bounded contexts 的概念。它们代表使用不同语言的边界。在某种程度上,它类似于 DCI 上下文。

在 DDD 中,我们也会有 Catalog 上下文和 Shipping 上下文。同样,我们会有电子书和数字产品的概念。不过,它们在这里不称为角色。此外,它可能更像是一个实现细节,但大多数 DDD 实现对于电子书(如目录)和数字产品(如运输)会有不同的对象(不同的身份)。

电子书和数字产品代表同一事物,很可能它们是其有限上下文中的聚合根。将它们保持为单独的对象(通常具有自己单独的持久性)需要某种同步机制。如果电子书标题发生变化,则可能需要在所有上下文中进行更改。在 DDD 中,领域事件是确保(通常是最终的)一致性的一种方式。

如您所见,不同类型的架构需要解决类似的问题。在这里,DDD和DCI都使用了面向角色的思想。但是,实现方式不同。