域驱动设计-父级处理子级

不要试图过早地解决潜在的性能问题(但也不要忽略它们)。

一如既往, 怎样 实际执行查询取决于数据的性质以及如何使用数据。如果有一个批处理进程正在运行数以万计的记录,那么您应该让sql server来处理它。

但是,如果只需要用较少的记录执行一次或两次查询,则可以使用内存循环。

你缺少的解决方案是:使用 查询规范 结束查询,并使 Author 对象使用此新查询规范。

一开始,只需要简单的循环。当您发现它太慢时,用对数据库的调用(通过 FindAwardWinningBookCount 你的方法 AuthorRepository )

重要的是 你的 作者 对象不再负责处理查询-它使用 查询规范 相反。更改查询规范的实现应该 不 影响 行为 你的 作者 。

更多细节见埃文书229至234页。

问题根本不是领域驱动的设计。是关于技术的。

从领域驱动的设计角度来看——正确地反映领域是很重要的(在这种情况下,当任何一本书获奖时,作者都会获奖)。模型中不存在与数据库相关的性能问题。

不幸的是,我们不能忽视他们。

但是帮你有点难。您没有指定要使用的技术。从提到延迟加载,我猜您正在使用orm。再说一遍-我不知道是哪一个。

我和nhibernate合作过,它很聪明,可以通过作者id外键来过滤图书,从而实现图书收藏的延迟加载。因此,这并不是因为我选择了所有的书,而是我需要的书。

在使用orm时,您可能不知道的另一个常见问题是 select n+1 problem 。

关于DDD…

不要停下来,不要以为你明白了。这真是个难以破解的难题。

我在当前的项目中大量使用orm(nhibernate),如果重要的话,我开始倾向于只记录一条信息。在你的情况下,我只是记录下他们是一个获奖作家。如果我需要找到这本书,我可以写一个特别的查询来找到他们所有获奖的书。这样做更有效率,然后把所有的书都装起来,只为了找出一个简单的事实。

我会给这个做个模型,这样作者就可以知道她/他是否赢了。当图书获奖时,它通知其作者(通过调用onbookbecameawardwinning方法)它获奖了。这种方法可以简单到在作者身上设置获奖标志,也可以复杂得多。这取决于具体情况。