我已经习惯了所有与现代.net编程有关的出版物和博客中普遍存在的所有典型的域驱动设计实践。因此，令我感到惊讶的是，当我与Django的一些人交谈时，他们并不关心持久性的无知， View 模型等。
当您在Django或Rails中使用Active Record时，缺乏持久性的无知部分似乎是可以理解的，在ASP.NET MVC领域中工作了一段时间之后，在 View 中使用域实体看起来完全是邪恶的(我想与Java mvc框架相同)。
这不是一个单独的案例，它涉及绝大多数Django/Rails项目(通常被视为Überagile)。
这是为什么？仅仅是因为动态的语言功能使像DI这样的实践变得不必要了吗？也许在企业级.NET/Java世界中有太多过度设计的问题？
您是否知道其他架构差异？在.net/java世界中，有什么要学习的类(class)吗？或者恰恰相反，仅仅是rubist和pythonistas通常没有与足够大的项目合作来理解这些模式的优势？
最佳答案
很好，已经有很多讨论了。这是我对此事的看法:
通常，直接为表单访问域模型要容易得多。这是在Rails中提供编码的东西之一(我不知道Django，但我猜是一样的)极大地提高了生产力。几乎没有任何编码需求:拥有一个数据库表，在中间构建一些html和一个简单的 Controller ，您就完成了。因为几乎不涉及任何代码，所以您可以更快地进行更改，这就是为什么它在敏捷环境中运行良好的原因。
但是，有时这还不够。有时，您的应用程序太复杂而无法正常工作。那时，您可以添加ViewModels，Presenter，Facade或任何您想调用的对象。在Rails或Django中，没有什么阻止您这样做的。实际上，Rails 3引入了ActiveModel作为一组混合对象，以使每个对象使用表单都像处理ActiveRecord一样容易。
所以问题不是为什么Rails和Django不这样做，而是我什么时候应该使用它？调用DDD过度设计也不是正确的。要做的是“足够公正”以解决您遇到的问题。保持尽可能少的代码量和复杂性，您将更易于维护。
我同意从Java/.NET中肯定可以吸取教训。通常他们会很好地完成设计模式。但是说Rubyists和Pythonistas没有做足够大的项目是不正确的。强大的功能在于识别何时可以使用简单的解决方案。
我确实认为Java程序员(我没有.NET程序员的经验)倾向于过度设计。也许是他们使用的框架。似乎试图迫使程序员以“正确的方式”来做到这一点，从而使其变得过于复杂。
关于ruby-on-rails - 典型的.NET DDD体系结构与Django/Rails的实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4432055/