扩展富域模型

Question

域驱动设计鼓励您使用丰富的域模型。这意味着所有域逻辑都位于域模型中，并且域模型是最高的。持久性成为外部关注的问题，因为领域模型本身对持久性一无所知(例如数据库)。

我已经在一个中等规模的单人项目(>100 k的Java行)上使用了这一点，并且我发现了许多优点，主要是与面向数据库的方法相比，它提供了灵活性和可重构性。我可以添加和删除域类，点击几个按钮和一个全新的数据库模式和SQL层展开。

但是，我经常会遇到这样的问题:我发现很难将富域逻辑与有SQL数据库支持应用程序这一事实相协调。通常，这会导致典型的"1+N查询问题“，即获取N个对象，然后对每个再次触发查询的对象执行一个非平凡的方法。手动优化此操作允许您在一定数量的SQL查询中执行此过程。

在我的设计中，我允许一个系统插入这些优化版本。为此，我将代码移动到一个“查询模块”中，其中包含数十个特定于域的查询(例如getActiveUsers)，其中既有内存中的查询(幼稚且不可扩展)，也有基于SQL的实现(供部署使用)。这使我可以优化热点，但有两个主要缺点：

• 实际上，我正在将我的一些域逻辑转移到不属于它的地方，实际上，甚至把它推到SQL语句中。
• 这个过程要求我仔细阅读查询日志，找出热点所在，之后我必须重构代码，通过将代码降为查询来降低其抽象程度。

是否有一种更好、更干净的方法来协调域驱动设计及其富域模型，以及不能将所有实体都存储在内存中，从而限制在数据库后端？

Answer 1

至少有两种方法来看待这个问题，一种是技术性的“我能做些什么来更智能地加载数据”版本。我所知道的唯一真正聪明的事情是动态集合，这些集合部分地加载了其余的按需加载，并可能预先加载了部分部件。在JavaZone 2008关于这一点有个有趣的演讲

第二种方法是我在使用DDD时所关注的重点；如何使我的模型更“可加载”，而不牺牲DDD的太多优点。多年来，我的假设一直是，很多DDD模型都是领域概念的模型，这些概念实际上是所有允许域状态的总和，跨越所有业务流程和每个业务流程中的不同状态。我相信，如果域模型在进程/状态方面得到更多的规范化，那么许多这些加载问题就会得到很大的减少。这通常意味着不存在"Order“对象，因为命令者通常存在于多个不同的状态中，这些状态具有相当不同的语义附加(ShoppingCartOrder、ShippedOrder、InvoicedOrder、HistoricalOrder)。如果您试图封装这是一个单一的Order对象，您总是会遇到许多加载/构造问题。

但这里没有银弹..。

Answer 2

根据我的经验，这是做事情的唯一方法。如果您编写了一个试图完全隐藏或抽象持久性层的系统，那么您就无法使用持久性层的细节来优化事情。

最近，我遇到了这个问题，并且一直在研究一种解决方案，持久性层可以选择实现表示优化的接口。我一直在玩它，但是用你的ListAUsers例子，它是这样的.

首先，编写一个在域级别上执行所有操作的ListAllUsers方法。在一段时间内，这将是可行的，然后它将开始变得太慢。

当使用富域模型变得缓慢时，创建一个名为"IListActiveUsers“的接口(或者更好的接口)。让您的持久性代码使用轮式技术实现这个接口是合适的(可能优化了SQL)。

现在，您可以编写一个层，检查这些接口，如果存在特定方法，则调用它。

这并不完美，我对这类事情也没有太多的经验。但在我看来，关键是确保如果您使用的是一种完全天真的持久性方法，那么所有的代码都应该仍然工作。任何优化都需要作为对此的补充。

Answer 3

不，不是真的。无论如何，我都不知道(尽管我有兴趣听到DDD的任何支持者对相反的反应)。

根据我自己的经验，以及与我一起工作的非常有经验的团队的经验，如果您想从数据库支持的应用程序中获得最佳的性能，那么其体系结构的转换是不可避免的。我编写了这里有更多关于这个的事情 (本文讨论了延迟加载的属性，但您可以考虑将其应用于类中任何需要检索更多数据以完成其工作的方法)。

正如您现在所做的那样，您可以从一个富域模型开始，并根据性能的需要将其转换为面向服务的模型。只要您已经定义了性能目标，并且正在实现它们，就没有必要改变一切。我认为这是一种相当体面的务实方法。