最近与一位同事就Rails应用程序中的模型设计和编码的不同方法进行了一场辩论，这让我在Rails的背景下了解了DCI。
然而，即使在浏览了这个示例应用程序之后，我似乎也无法理解整个概念。
目前，在编写Rails应用程序时，我倾向于或多或少地"照本宣科"。
因此，我想问几件事——
- 什么是DCI？与普通的旧MVC（以及Rails中的普通ActiveRecord）相比，与MVC一起实现DCI有什么优势
- 它如何在Rails中实现（或者换句话说，所有模块都有什么）
编辑
我想在RoR的上下文中进一步扩展我的问题——是否推荐Rails中模型和控制器之间的另一个抽象级别？它在不同规模的应用中有多广泛？
DCI是一种范式，因此远不止是设计应用程序的一种方式。这是一种思考建模和结构化代码的方式。DCI的一个重要部分是将系统是什么（域模型）和系统做什么（功能）分开。DCI与MVC解决相同问题的方法没有什么不同，所以你的第一个问题无法真正得到回答。您可以同时使用MVC和DCI，这并非巧合，因为Trygve Renskaug是MVC和DCI之父。他最近在谷歌小组"对象合成"上回答了一个类似的问题。
你链接的例子违反了一些基本思想，比如让角色对上下文保密，我实际上也找不到一个上下文，但这可能是因为只花了很短时间浏览代码。
我不了解RoR，所以我不能给你一个RoR的例子，但如果你去fullOO，你会发现用不同语言写的例子，包括Ruby和Marvin，这是为DCI设计的第一种语言。
EDIT"什么是DCI"这个问题没有简单的答案，DCI是一种范式，就像OOP是一种范型一样。它们都有相同的根源，回答上述问题就像回答"什么是面向对象编程"一样复杂。DCI是面向对象的，而所有主要OO语言中的OOP实际上是面向类的，而不是面向对象的。DCI旨在生成运行时对象之间的交互在编译时代码中可见的代码，并且更一般地说，它试图通过读取代码来更容易地推断运行时行为。我链接到上面的网站致力于解释DCI的全部内容，并列出了多种语言的示例。Ruby是之一
编辑有一本关于ruby和DCI的书即将出版。作者对对象组合非常活跃，对非常深入
对于那些想知道DCI代表什么的人来说。。
DCI代表Data Context Interaction
DCI的核心是它为开发人员提供的认知工具。我不确定你是否看过James Coplien/Trygve Reenskaug所有伟大的讲座，但我会努力为任何新概念的人提炼出它的要点。它是关于将系统行为从系统的交互域对象（数据实体或系统是什么）转移到行为对象（系统做什么）中，作为第一类公民，通过在用例上下文中及时为对象注入功能来调解对象之间的协作。
想想BDD。我们不是在许多对象之间对行为进行编码，比如在与持久层高度耦合的数据对象中分布的功能粒子，而是在仅为用例（故事）而存在的内聚对象中进行编码，这些内聚对象将功能注入并协调这些哑数据对象的交互。就像物理体系结构的纯粹层一样，缓慢变化的数据对象不会一直携带快速变化的功能实现。相反，Ruby为我们提供了在运行时仅在用例上下文中需要时将行为轻松注入对象的能力。
作为ROR中的一个例子，如果您在一个用例中有一个控制器操作，其中存在一个事件概率矩阵，其中大多数条目可能只在一小部分请求中被触发，那么实例化一个由行为繁重的臃肿对象组成的网络，并知道为数据的每个可能用例执行每个事件是不必要的。此外，不必在我的文本编辑器中挖掘18个文件来理解交互是如何工作的，与将所有逻辑干净地抽象为由上下文对象提供的接口中的模式相比，这也是一个明显的优势。
关于你关于rails中控制器和模型之间"另一层"抽象的问题，我不确定你指的是哪一层。无论如何，是的。无论如何。没问题。设计模式和Bobs叔叔的SOLID原则是OO设计中公认的最佳实践。这两者都强烈鼓励在策略和实现之间进行松散耦合的抽象。它们都有助于避免罗马帝国毁灭性的非地转性大脑转储，因为它们提供了一个大家都理解的共同框架。对我来说，DCI提供了相同类型的认知框架，但它使系统更容易理解和有效处理，这是任何面向对象的设计师的圣杯。
有一本关于在Ruby/Rails中使用DCI的书（目前正在进行中）：Clean Ruby。我强烈建议你把自己列入通知名单——我读过这本书的部分内容，它看起来真的很好。
DCI在Rails世界中越来越受欢迎——在过去的三个月左右，有很多关于它的有趣的博客文章。