oop – DDD – 持久化模型和领域模型

但是，这是如果你正在寻找纯DDD和你的项目值可扩展性和性能超过初始开发的速度。很多时候，将基础设施问题与您的“域模型”混合可以帮助您以可扩展性为代价，在速度上取得巨大进步。关键是，你需要问自己：“纯DDD的好处是否值得在开发速度上的成本？如果你的答案是肯定的，那么这里是你的问题的答案。

让我们从一个例子开始，你的应用程序开始与域模型，只是这样发生，数据库中的表匹配您的域模型。现在，您的应用程序会根据跳跃和边界增长，并且在查询数据库时开始遇到性能问题。你已经应用了一些精心设计的索引，但是你的表增长如此之快，它看起来像你可能需要反标准化你的数据库只是为了跟上。所以，在dba的帮助下，你想出了一个新的数据库设计，将处理你的性能需求，但现在的表与以前的方式有很大的不同，现在块的实体分布在多个表，而不是而不是每个实体的一个表。

这只是一个例子，但它演示了为什么你的域模型应该与持久性模型分开。在本示例中，您不想分拆域模型的类以匹配对持久性模型设计所做的更改，并且实质上更改域模型的含义。相反，您要更改新的持久性模型和域模型之间的映射。

保持这些设计分离有几个好处，例如可扩展性，性能和对紧急数据库更改的反应时间，但是您应该根据初始开发的成本和速度进行权衡。一般来说，将从这种分离水平中获益最大的项目是大型企业应用程序。

更新评论者

在软件开发的世界中，存在第N个可能的解决方案。因此，在灵活性和初始发展速度之间存在间接的反比关系。作为一个简单的例子，我可以硬编码逻辑到类中，或者我可以编写一个类，允许动态逻辑规则传递到它。前一种选择方案将具有较高的发展速度，但是以较低程度的灵活性为代价。后一种选择将具有较高程度的灵活性，但代价是较低的发展速度。这在每种编码语言中都成立，因为总是存在N个可能的解。

许多工具可用于帮助您提高初始开发速度和灵活性。例如，ORM工具可以提高数据库访问代码的开发速度，同时还可以灵活地选择ORM支持的特定数据库实现。从你的角度来看，这是时间和灵活性的净收益减去工具的成本(其中一些是免费的)，这可能是或不可能是值得的，基于开发时间的成本相对于业务需要。

但是，对于这种编码风格的交谈，这本质上是域驱动设计，你必须考虑到你使用它编写的工具花费的时间。如果你写的是ORM工具，或者甚至编写你的数据库访问逻辑，它支持所有的工具给你的实现，这将需要比如果你只是硬编码的具体实现你计划使用。

总之，工具可以帮助您抵消自己的生产时间和灵活性的价格，通常通过将该时间的成本分配给购买该工具的每个人。但是，包括使用工具的代码的任何代码将仍然受速度/灵活性关系的影响。以这种方式，域驱动设计允许更大的灵活性，比如果你纠缠的业务逻辑，数据库访问，服务访问和UI代码在一起，但是以生产的时间为代价。域驱动设计为企业级应用程序提供优于小型应用程序的优势，因为企业级应用程序往往在初始开发时间方面具有较高的成本，因为它们更复杂，它们也更容易发生变化，需要更大的灵活性降低成本。