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屋！
