DDD - 持久性模型和领域模型 [英] DDD - Persistence Model and Domain Model
问题描述
我正在尝试学习领域驱动设计 (DDD)，并且我想我已经掌握了基本思想.但有件事让我感到困惑.
I am trying to learn domain-driven design (DDD), and I think I got the basic idea. But there is something confusing me.
在 DDD 中，持久模型和域模型是不同的东西吗?我的意思是，我们设计我们的领域和类时只考虑领域问题；没关系.但是在那之后，当我们构建我们的存储库或任何其他数据持久性系统时，我们是否应该为我们的模型创建另一个表示以在持久层中使用?
In DDD, are the persistence model and domain model different things? I mean, we design our domain and classes with only domain concerns in mind; that's okay. But after that when we are building our repositories or any other data persistence system, should we create another representation of our model to use in persistence layer?
我认为我们的领域模型也用于持久性，这意味着我们的存储库从查询中返回我们的领域对象.但是今天看了这个帖子，有点懵:
I was thinking our domain model is used in persistence too, meaning our repositories return our domain objects from queries. But today, I read this post, and I'm a little confused:
如果这是真的，将持久性对象与域对象分开有什么好处?
If that's true what would be the advantage of having separate persistence objects from domain objects?
推荐答案
只要这样想，域模型应该不依赖任何东西，并且其中没有基础结构代码.域模型不应可序列化或从某些 ORM 对象继承，甚至不应共享它们.这些都是基础设施问题，应该与领域模型分开定义.
Just think of it this way, the domain model should be dependent upon nothing and have no infrastructure code within it. The domain model should not be serializable or inherit from some ORM objects or even share them. These are all infrastructure concerns and should be defined separate from the domain model.
但是，如果您正在寻找纯 DDD，并且您的项目重视可扩展性和性能而不是初始开发速度.很多时候，将基础设施问题与您的域模型"混合可以帮助您以可扩展性为代价在速度上取得巨大进步.关键是，您需要问自己，纯 DDD 的好处是否值得以开发速度为代价?".如果您的回答是肯定的，那么这里就是您问题的答案.
But, that is if you're looking for going for pure DDD and your project values scalability and performance over speed of initial development. Many times, mixing infrastructure concerns with your "domain model" can help you achieve great strides in speed at the cost of scalability. The point is, you need to ask yourself, "Are the benefits of pure DDD worth the cost in the speed of development?". If your answer is yes, then here is the answer to your question.
让我们从一个示例开始，其中您的应用程序以域模型开始，而数据库中的表恰好与您的域模型完全匹配.现在，您的应用程序突飞猛进地增长，您在查询数据库时开始遇到性能问题.您已经应用了一些经过深思熟虑的索引，但是您的表增长得如此之快，以至于您可能需要对数据库进行反规范化才能跟上.因此，在 dba 的帮助下，您提出了一种新的数据库设计来满足您的性能需求，但是现在这些表与以前的方式大不相同，现在域实体的块分布在多个表中，而不是而不是每个实体都有一张桌子.
Let's start with an example where your application begins with a domain model and it just so happens that the tables in the database match your domain model exactly. Now, your application grows by leaps and bounds and you begin to experience performance issues when querying the database. You have applied a few well thought out indexes, but your tables are growing so rapidly that it looks like you may need to de-normalize your database just to keep up. So, with the help of a dba, you come up with a new database design that will handle your performance needs, but now the tables are vastly different from the way they were before and now chunks of your domain entities are spread across multiple tables rather than it being one table for each entity.
这只是一个例子，但它说明了为什么你的领域模型应该与你的持久性模型分开.在此示例中，您不希望分解域模型的类以匹配您对持久性模型设计所做的更改，并从本质上改变域模型的含义.相反，您想要更改新持久性模型和域模型之间的映射.
This is just one example, but it demonstrates why your domain model should be separate from your persistence model. In this example, you don't want to break out the classes of your domain model to match the changes you made to the persistence model design and essentially change the meaning of your domain model. Instead, you want to change the mapping between your new persistence model and the domain model.
将这些设计分开有几个好处，例如可扩展性、性能和对紧急数据库更改的反应时间，但您应该权衡它们与初始开发的成本和速度.通常，从这种级别的分离中获得最大收益的项目是大型企业应用程序.
There are several benefits to keeping these designs separate such as scalability, performance, and reaction time to emergency db changes, but you should weigh them against the cost and speed of initial development. Generally, the projects that will gain the most benefit from this level of separation are large-scale enterprise applications.
评论员更新
在软件开发领域，有第 N 种可能的解决方案.正因为如此，灵活性和初始发展速度之间存在着间接的反比关系.作为一个简单的例子，我可以将逻辑硬编码到一个类中，或者我可以编写一个允许将动态逻辑规则传递给它的类.前一种选择具有更高的开发速度，但代价是灵活性较低.后一种选择将具有更高程度的灵活性，但代价是开发速度较低.这适用于每种编码语言，因为总是有第 N 个可能的解决方案.
In the world of software development, there is Nth number of possible solutions. Because of this, there exists an indirect inverse relationship between flexibility and initial speed of development. As a simple example, I could hard code logic into a class or I could write a class that allows for dynamic logic rules to be passed into it. The former option would have a higher speed of development, but at the price of a lower degree of flexibility. The latter option would have a higher degree of flexibility, but at the cost of a lower speed of development. This holds true within every coding language because there is always Nth number of possible solutions.
有许多工具可以帮助您提高初始开发速度和灵活性.例如，ORM 工具可以提高数据库访问代码的开发速度，同时还使您可以灵活地选择 ORM 支持的任何特定数据库实现.从您的角度来看，这是时间和灵活性的净收益减去工具成本(其中一些是免费的)，根据开发时间成本相对于工具的价值，这对您来说可能值得也可能不值得业务需要.
Many tools are available that help you increase your initial development speed and flexibility. For example, an ORM tool may increase the speed of development for your database access code while also giving you the flexibility to choose whatever specific database implementations the ORM supports. From your perspective, this is a net gain in both time and flexibility minus the cost of the tool (some of which are free) which may or may not be worth it to you based on the cost of development time relative to the value of the business need.
但是，对于这种编码风格的对话，本质上就是领域驱动设计，您必须考虑编写您正在使用的工具所花费的时间.如果您要编写该 ORM 工具，甚至以支持该工具为您提供的所有实现的方式编写数据库访问逻辑，则与仅对计划的特定实现进行硬编码相比，需要花费更长的时间使用中.
But, for this conversation in coding styles, which is essentially what Domain Driven Design is, you have to account for the time it took to write that tool you're using. If you were to write that ORM tool or even write your database access logic in such a way that it supports all of the implementations that tool gives you, it would take much longer than if you were to just hard-code the specific implementation you plan on using.
总而言之，工具可以帮助您抵消自己的生产时间和灵活性的成本，通常是通过将这段时间的成本分摊给购买该工具的每个人.但是，任何代码，包括使用工具的代码，都会受到速度/灵活性关系的影响.通过这种方式，与将业务逻辑、数据库访问、服务访问和 UI 代码纠缠在一起相比，领域驱动设计提供了更大的灵活性，但以生产时间为代价.领域驱动设计比小型应用程序更好地服务于企业级应用程序，因为企业级应用程序在与业务价值相关的初始开发时间往往具有更高的成本，并且由于它们更复杂，它们也更容易发生变化，需要更大的灵活性及时降低成本.
In summary, tools can help you to offset your own time to production and price of flexibility, often by distributing the cost of that time to everyone who purchases the tool. But, any code including the code that utilizes a tool, will remain affected by the speed/flexibility relationship. In this way, Domain Driven Design allows for greater flexibility than if you were entangle your business logic, database access, service access, and UI code all together, but at the cost of time to production. Domain Driven Design serves Enterprise level applications better than small applications because Enterprise level applications tend to have a greater cost for the initial development time in relation to business value and because they are more complex, they are also more subject to change requiring greater flexibility at a reduced cost in time.
这篇关于DDD - 持久性模型和领域模型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
