DDD-贫血域模型是反模式吗？我们应该使用富域模型吗？[关闭]

Enes 和Fowler很久以前就批评了贫血症领域模型，因为它显然违反了面向对象的原理等。DDD社区显然与此声明保持一致。

但是，近年来，一直有不同意见的人声称它根本不是反模式，并且它是遵循SOLID原则的一个示例。

我已经使用Spring Framework工作了很多年。每个公司中的每个项目都始终使用服务于贫乏模型（JPA实体）的存储库，其中包含业务逻辑的服务层。此外，大多数样本，甚至包括Spring员工的官方样本，都展示了这种工作方式。

我的问题是：贫血领域模型是否仍被视为反模式？我们所有人都在做关于DDD的事情吗？您是否不认为拥有Rich Domain模型违反了SOLID原则？

ADM是解决诸如微服务之类的分布式服务的好模式。它适合当今许多基于Web的业务案例。

考虑是否有一个Order Domain对象。使用OOP方法，我们可以添加Order.Purchase（）Order.Cancel（）等。它在桌面应用程序中可以很好地工作，在桌面应用程序中，我们将订单保存在内存中，并对同一个实例执行多项操作。

但是，如果我们有一个分布式系统，并且该程序只处理一件事，即访问一个订单列表并依次购买每个订单，或者获取一个订单列表并依次取消每个订单，那么将两个Method放在同一个对象上将不会感。我们将必须具有两个域或有界上下文：

PurchaseSystemOrder.Purchase()

和

CancelSystemOrder.Cancel();

这些对象唯一共享的是属性的数据结构。

随着您添加越来越多的微服务，您最终获得了数十种订单。将 Order称为Domain对象不再有意义，即使它与所有这些系统正在处理的概念顺序相同。

有一个Anemic模型Order更有意义，该模型仅封装数据并相应地重命名服务：

PurchaseService.Purchase(Order order)

现在，我们可以再次讨论Order，我们可以添加我们认为可以处理的任何新服务，而不会影响其他当前已部署的服务。

Fowler和Co来自整体系统背景，在他们的世界中，ADM方法将意味着在内存中实例化所有这些独立服务并传递和更改OrderDTO的单个应用程序。这比将这些方法置于丰富的Order模型上要糟糕得多。

但是在分布式系统中，有很多程序，每个程序仅需要一个Order方法，并以多个订单运行它，加载每个程序，运行该方法，然后将其丢弃。它只需要一个Service和一个数据对象流。

完全填充一个丰富的模型，担心所有方法的需求和依赖性仅调用一个模型然后几乎立即丢弃该对象是没有意义的。

加上对其中一种方法的更改，将需要更新所有分布式组件，因为它们都依赖于Rich Model的逻辑。

我的代码库中没有空间容纳他们不需要的东西

SOLID和DDD彼此正交，这意味着它们实际上彼此之间的方向不同。您不应该说一个习惯于另一个，因为它们可以并且应该一起存在于同一代码库中。

只有当您的问题域有很多行为并且您有数百种带有复制粘贴逻辑或依赖项的服务方法时，贫血域模型才成为反模式。服务层方法必须调用其他服务层方法才能完成任何事情。

由于有限的上下文概念，DDD是微服务的绝佳范例。

注意将基础结构代码视为您的域的一部分的诱惑。基础结构代码是您自己没有编写的任何东西，或者是与与第三方系统交互的框架或库耦合的任何东西。数据库连接，SMTP邮件程序，ORM库，应用程序服务器运行时间，所有这些都是基础架构，如果可以避免的话，您不应在域中包括或依赖它。

SOLID原则是一组通用的OOP概念，可用于编写更好的OOP代码。您可以使用它们编写良好的DDD代码库。

如果做得好，丰富的域名会很好。不做噩梦。贫血域总是不好的。但是它熟悉的舒适有点不好。

如果仅是贫血域，则在选择通用语言时会选择错误的语言。第四代语言专门针对特定用途。如果贫血病足够好，使用它们会让您的生活更轻松。

许多框架会进入语言空间，直到您不再将其作为Java作业来宣传。这是Java / Spring工作。他们所做的，除了使您依赖于他们之外，还将通用语言转变为第四代语言的混蛋形式。

这是最佳实践还是反模式？好吧，您的老板大多只是在乎您是否可以聘请人员在代码库上工作。因此，如果我们必须假装我们正在使用通用语言来招聘人员，我们会的。

如果可以的话就可以了。您当然不是唯一的一个。

但是不要告诉我这是必须的。不要告诉我，它为我做的事情比做的更多。我知道没有它怎么生活。我知道如何推出它，因此只有几件事取决于它。如果您要我屈服并让一切接管仅仅是为了与之抗争，那是的，我认为这很糟糕。

我的代码库中没有多余的空间。

至于SOLID和其他设计原则，即使在贫瘠的领域中，我也可以在很大程度上遵循这些原则。不遵循它们会导致另一种问题。