领域建模如何与某些数据库优化共存？

Question

我目前正在处理一个.NET项目，为了提高效率，我们希望直接在数据库上执行一些计算(例如，执行一个连接并依靠数据库来检查用户是否拥有执行某些操作的权限，而不是检索实体)。

但是，我不确定这将如何与系统的域建模交互，据我所知，域模型应该独立于IO和其他外部系统。域模型文档/帐户应该用于对DB的这些查询，还是有更好的方法来做到这一点？

Answer 1

域模型文档/帐户应该用于对DB的这些查询，还是有更好的方法来做到这一点？

真正的答案-很好。

没有任何规则规定您的所有域代码都需要在相同的代码中实现，在同一个进程中运行，或者位于单个主机上。

Udi Dahan经常强调逻辑与物理之间的区别；您可以在逻辑上拥有位于不同物理服务器上的域的一部分代码。

当然，这也不是没有它的挑战--即使在将域代码与“管道”分开的数据库中也是一个好主意，而在存储设备中运行域代码这一事实意味着您有一些额外的体系结构约束，而这些约束可能并不明显--所以您需要一些架构决策记录来解释您从存储设备中需要的真正功能。

域模型应该独立于IO和其他外部系统。

“独立”可能会误导你。

我通常是这样描述分离的:域模型涉及到表示域中信息的操作。但通常情况下，这与信息的存储和传输无关。

在理想的情况下，我们可以按原样获取域模型，并将其移动到主机，而且一切都应该仍然正常工作。例如，如果我们将域模型从命令行工具移动到通过web接口访问的东西，这不会改变域模型本身处理信息的方式。类似地，当我们将存储从一种设备转移到另一种设备时，域规则不会改变。

又名：“关注点分离”。

是的，有时我们会将域模型(或域模型的一部分)移动到不支持当前模型实现的平台上，我们必须重写。

Answer 2

我将告诉您为什么不应该这样做，而不是回答数据库优化如何与域模型共存。

埃里克·埃文斯写了一本书“领域驱动的设计:解决软件中心的复杂性”。

软件的核心是领域模型。这就是解决复杂问题的地方。另一方面，数据库是一个相当不重要的细节，我们通常需要某种机制来存储域的状态，但仅此而已。我们不希望数据库在域模型方面扮演重要角色，因为这意味着我们的业务规则现在被分割在两个地方。有几个业务规则所在的地方越来越复杂，这正是我们试图用DDD来阻止的。

如果您没有实际的性能问题，我将在域模型中进行计算，以使其尽可能显式。

如果您确实有实际的性能问题，那么其中一个技巧就是将决策所需的数据与实际的决策分离开来。不要问数据库用户是否可以执行某个操作，而是向域模型提供作出决策所需的数据。这样，您仍然可以优化数据库中的查询，但是业务逻辑仍然封装在域模型中。