我正在尝试学习领域驱动设计(DDD)，我想我已经掌握了基本的想法。但是有一点让我感到困惑。
在 DDD 中，持久模型和域模型是不同的东西吗？我的意思是，我们设计我们的领域和类时只考虑领域问题；没关系。但是在那之后，当我们构建我们的存储库或任何其他数据持久性系统时，我们是否应该为我们的模型创建另一个表示以在持久层中使用？
我认为我们的领域模型也用于持久性，这意味着我们的存储库从查询中返回我们的领域对象。但是今天，我看了这篇文章，我有点困惑:
Just Stop It! The Domain Model Is Not The Persistence Model
如果这是真的，那么将持久对象与域对象分开有什么好处？
最佳答案
这样想一下，域模型应该不依赖任何东西，并且其中没有基础结构代码。域模型不应可序列化或从某些 ORM 对象继承，甚至不应共享它们。这些都是基础设施问题，应该与领域模型分开定义。
但是，如果您正在寻找纯 DDD，并且您的项目重视可扩展性和性能而不是初始开发速度。很多时候，将基础设施问题与您的“域模型”混合可以帮助您以可扩展性为代价在速度上取得巨大进步。关键是，您需要问自己，“纯 DDD 的好处是否值得以开发速度为代价？”。如果您的回答是肯定的，那么这里就是您问题的答案。
让我们从一个示例开始，其中您的应用程序以域模型开始，而数据库中的表恰好与您的域模型完全匹配。现在，您的应用程序突飞猛进地增长，您在查询数据库时开始遇到性能问题。您已经应用了一些经过深思熟虑的索引，但您的表增长如此之快，以至于您可能需要对数据库进行反规范化才能跟上。因此，在 dba 的帮助下，您提出了一个新的数据库设计来满足您的性能需求，但现在这些表与以前的方式大不相同，现在域实体的块分布在多个表中，而不是而不是每个实体都有一张 table 。
这只是一个示例，但它说明了为什么您的域模型应该与您的持久性模型分开。在此示例中，您不希望拆分域模型的类以匹配您对持久性模型设计所做的更改，并从本质上改变域模型的含义。相反，您希望更改新持久性模型和域模型之间的映射。
将这些设计分开有几个好处，例如可扩展性、性能和对紧急数据库更改的 react 时间，但您应该权衡它们与初始开发的成本和速度。通常，将从这种级别的分离中获得最大 yield 的项目是大型企业应用程序。
评论员更新
在软件开发领域，可能的解决方案有 N 种。正因为如此，灵活性与初始发展速度之间存在着间接的反比关系。作为一个简单的例子，我可以将逻辑硬编码到一个类中，或者我可以编写一个允许将动态逻辑规则传递给它的类。前一种选择具有更高的开发速度，但代价是灵活性较低。后一种选择将具有更高程度的灵活性，但代价是开发速度较低。这适用于每种编码语言，因为总是有第 N 个可能的解决方案。
有许多工具可以帮助您提高初始开发速度和灵活性。例如，ORM 工具可以提高数据库访问代码的开发速度，同时还可以让您灵活地选择 ORM 支持的任何特定数据库实现。从您的角度来看，这是时间和灵活性的净 yield 减去工具成本(其中一些是免费的)，根据开发时间成本相对于工具的值(value)，这对您来说可能值得也可能不值得业务需要。
但是，对于这种编码风格的对话，本质上就是领域驱动设计，您必须考虑编写您正在使用的工具所花费的时间。如果您要编写该 ORM 工具，甚至以支持该工具提供的所有实现的方式编写数据库访问逻辑，则与仅对计划的特定实现进行硬编码相比，需要花费更长的时间在使用。
总之，工具可以帮助您抵消自己的生产时间和灵活性的价格，通常是通过将时间成本分配给购买工具的每个人。但是，任何代码，包括使用工具的代码，都会受到速度/灵活性关系的影响。通过这种方式，与将业务逻辑、数据库访问、服务访问和 UI 代码纠缠在一起相比，领域驱动设计提供了更大的灵活性，但以生产时间为代价。领域驱动设计比小型应用程序更好地服务于企业级应用程序，因为企业级应用程序在与业务值(value)相关的初始开发时间往往具有更高的成本，并且由于它们更复杂，它们也更容易发生变化，需要更大的灵活性。及时降低成本。
关于oop - DDD - 持久性模型和领域模型，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14024912/