为什么域驱动设计似乎只受C#和Java等静态语言的欢迎？

OOP表现力

在诸如Python和Ruby之类的动态语言中，您没有接口和抽象类之类的所有OOP功能。有时在使代码表达和清晰方面带来一些困难。

单元测试

您需要编写更多的单元测试来替换编译器可以为您完成的工作。

动态打字

如果要进行某种类型检查，则需要使用鸭子类型。编译器没有帮助。

避免典型地狱

在OOP动态语言还是静态语言之间进行选择时，总会有权衡取舍。在诸如C＃和Java之类的静态类型语言中，一个常见的问题是，有时类型系统会使代码表现得非常缺乏表达力和冗长。一些开发人员倾向于陷入泛型类型的地狱。但并非所有静态类型的语言都存在此问题（F＃是其中一种-由于强类型推断）。

测试中

在某些情况下，例如当您不想创建仅用于注入类并使其可测试的接口时，不使用静态类型也有帮助。在这些情况下，接口不利于可读性，实际上会损害可读性，因为您需要创建一个哑巴文件（接口），该哑巴文件不代表测试代码的欲望。在Ruby中，您可以通过多种方式来执行此操作而无需创建接口，其中一个示例是：

class DispatchOrderService
  def initialize(overrides = {})
    @repository = overrides.fetch(:repository) do
      ::Infra::OrderRepository.new
    end

    @mail_service = overrides.fetch(:mail_service) do
      ::Infra::MailService.new
    end
  end

  def dispatch(order)
    order.dispatched
    repository.save(order)
    mail_service.notify_order_dispatched(order)
  end
end

是的，通过这种方法，我们打破了简洁的体系结构，因为该类知道具体的“ infra”实现。但它是可以与依赖注入来解决（Ruby的这些框架总是打破干净架构太或太丑陋有人想用它，在我们的项目中，我们通过实例的依赖关系做了我们自己的DI容器的一个问题手动上项目启动）。

综上所述，我认为即使在静态语言中比较困难的情况下，也可以在Ruby中编写良好的“企业” DDD应用程序。我当前的项目就是一个例子（6万行代码并且仍可维护）。

@GeorgeMaueris提到的观点也很重要。您可能会在框架中实施DDD时遇到问题，这些问题使您无法组织代码。因此，在这里我们选择使用Hanami而不是Rails，但即使Hanami也是我们想要的“意见”。我真的不建议任何人寻找“框架”来构建DDD。设计/体系结构随应用程序的不同而变化，并且也在不断发展。当您选择“ DDD”框架时，有时您会面临与之抗争的情况（执行变通办法或修补程序）。

因此，也许您可​​以问我为什么我们完全选择红宝石。在这里使用Ruby的要点是，几乎100％的团队都是由Ruby开发人员组成的，我们不想重复这些困难：学习DDD +一种新的编程语言。更具战略意义而非纯粹的技术决定。没有它，公司（一家初创公司）可能不会走得那么远。

对于基于DDD方面的项目，我们放弃了Ruby和Python。现在我们正在使用Kotlin，感到非常满意。主要的好处在这里列出：

IntelliJ的最佳IDE支持。这使我们的重构速度大大提高，在编译时产生了错误，并且减少了为编译器可以为我们做的事情编写测试的工作。

良好且流行的依赖注入，ORM，函数式编程框架

语言本身的另一个好处（空安全性，数据类等）

编辑2019：

我们写了一系列关于从Ruby到Kotlin的文章。你可以在这里看到它。