软件工程中的所有架构方法都旨在解决类似的问题。经常使用的技术之一是 角色 的概念。
当您进行 OOP 时，您可能会使用接口（尤其是静态类型语言）。接口帮助我们思考角色——在这种情况下，这是对象所扮演的角色。
DCI架构是反对现在的面向类的思想。他们的目标是引入基于对象的完整 OOP，而不是像我们现在习惯的那样基于类。为了稍微简化一下，在 DCI 中，您应该能够在对象的基础上而不是在类级别上实现接口。
例如，如果您有一个电子书对象，您可能希望在 Shipping 上下文（通过电子邮件将其交付给客户）中暂时将其视为“数字产品”。并非所有电子书都在同一时间交付，因此所有电子书（在班级级别）都具有运输能力是没有意义的。目前，当发布数字产品很重要时，电子书就扮演了新的角色。当它在另一个上下文中使用时（在目录中列出？）它没有作用 - 它没有一些方法。
这是 DCI 使用角色的概念方式。
现在，什么是 DDD 方式？
在 DDD 中，我们使用 bounded contexts 的概念。它们代表使用不同语言的边界。在某种程度上，它类似于 DCI 上下文。
在 DDD 中，我们也会有 Catalog 上下文和 Shipping 上下文。同样，我们会有电子书和数字产品的概念。不过，它们在这里不称为角色。此外，它可能更像是一个实现细节，但大多数 DDD 实现对于电子书（如目录）和数字产品（如运输）会有不同的对象（不同的身份）。
电子书和数字产品代表同一事物，很可能它们是其有限上下文中的聚合根。将它们保持为单独的对象（通常具有自己单独的持久性）需要某种同步机制。如果电子书标题发生变化，则可能需要在所有上下文中进行更改。在 DDD 中，领域事件是确保（通常是最终的）一致性的一种方式。
如您所见，不同类型的架构需要解决类似的问题。在这里，DDD和DCI都使用了面向角色的思想。但是，实现方式不同。