model - 扩展富域模型

Question

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

我一直在一个中等规模的单人项目(> 100k 行 Java)中使用它，我发现了许多优点，主要是它提供的灵 active 和可重构性，而不是面向数据库的方法。我可以添加和删除域类，点击几个按钮，一个全新的数据库模式和 SQL 层就会推出。

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

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

我正在有效地将我的一些域逻辑移动到它并不真正属于的地方，实际上甚至将其插入 SQL 语句中。

这个过程需要我仔细阅读查询日志以找出热点在哪里，然后我必须重构代码，通过将其降低到查询中来降低其级别抽象。

有没有更好、更简洁的方法来协调域驱动设计及其富域模型与您不能将所有实体都保存在内存中并因此仅限于数据库后端的事实？

Answer 1

至少有两种方法可以看待这个问题，一种是技术“我可以做些什么来更智能地加载我的数据”版本。我知道的唯一真正聪明的事情是动态集合，这些集合部分加载，其余部分按需加载，可能预加载部分。在 JavaZone 2008 about this 有一个有趣的谈话

在我使用 DDD 时，第二种方法更受我关注。如何在不牺牲太多 DDD 优点的情况下制作我的模型，使其更“可加载”。多年来我的假设一直是，许多 DDD 模型对领域概念进行建模，这些领域概念实际上是所有允许的领域状态的总和，跨越所有业务流程以及随着时间的推移在每个业务流程中出现的不同状态。我相信，如果域模型在进程/状态方面稍微标准化一点，那么很多这些加载问题都会大大减少。这通常意味着没有“Order”对象，因为一个订单通常存在于多个不同的状态，这些状态具有相当不同的语义(ShoppingCartOrder、ShippedOrder、InvoicedOrder、HistoricalOrder)。如果您尝试将其封装为单个 Order 对象，您总是会遇到很多加载/构造问题。

但是这里没有 Elixir ..