如何选择DDD总结？ [英] How to choose DDD Aggregate?
问题描述
在图书的应用领域驱动设计，具有点的 4在C＃中的第4章（第一个素描）的例子。并发冲突检测是非常重要的我不明白为什么笔者有选择这个aggregates.Customer有他自己的骨料和秩序都有自己的总和。
我认为客户应该有他的命令的参考。
订单有身份的只有一个客户。我没有看到一种情况下他的ID来从数据库中获得订单。但是，如果我申请这个逻辑的话，在我的域模型，我有一个包含所有我的实体和值对象的几个复杂的集合体。我不想这样。
在得到它不会直接装入他的命令（延迟加载）数据库中的客户。因此，这不是一个参数。
如果客户应用于不同场景，那么最好以清除客户，在一个场景中引用时才有用。我想，这是一个原因让一个聚合秩序和有一个间接引用，以他的命令。
那么，什么是选择一个聚合的真正原因？
我有另外一个误区。为了有更多的订单行。订单行有一个产品。为什么允许作为订单行不得不聚集秩序之外的对象（产品）的参考？
我觉得客户应该有他的命令参考
与实施的存储库查询的对象引用的替代品。 的正是在这些类型的，其中有一个客户和一个顺序之间的关系的情况下是有用的，但它没有意义实现为对象引用。之所以如此，有几个原因。其中之一是，它可能不加载与客户相关联的所有订单可行的。即使使用延迟加载，您通常会希望有一个分页集合。另一个原因是笔者称之为并发冲突检测，这也被称为事务一致性的。有没有涉及与客户和引用的所有订单不用相关联的所有订单的任何行为。
在从数据库中获取客户它不能直接加载自己的
级（延迟加载）。因此，这不是一个参数。
延迟加载的可能会产生问题。主要的原因是难和缺乏实施的灵活性，以及在以推理代码的能力下降。
那么什么是真正的原因选择一个聚合？
这是总应该是一致的边界。换言之，聚集体限定一组实体和值的对象必须保持在对应于所述骨料的行为相一致。这有业务和技术的后果。看看有效整合设计了解这一点。
为什么允许作为订单行有一个对象
（产品）合计秩序之外的参考？
通常情况下，一个订单行应引用代表订购的产品，而不是实际的产品实体的参考值对象。这是部分由于讨论骨料的限制，但也因为订单是一个事件，应该是一成不变的。
In book Applying Domain-Driven Design With Examples in C# in Chapter 4 (A first Sketch) on point 4. Concurrency Conflict Detection Is Important i don't understand why the author has choose this aggregates.Customer has his own aggregate and Order has his own aggregate.
I think Customer should have a reference to his orders.
Order have identity only with a customer. I'm not see one situation to get an order from database by his id. But if I apply this logic then, in my domain model, I have few complex aggregates that contain all of my entities and values objects. I don't want this.
When get a customer from the database it will not load directly his orders (Lazy Loading). So this is not an argument.
If customer is used in different scenarios then it's better to clear customer for that references only useful in one scenario. I guess that this is one reason for make an aggregate for order and have an "indirect reference" to his orders.
So what are the real reasons for choosing an aggregate?
I have another misunderstanding. Order has more OrderLine. OrderLine has one product. Why is permitted as OrderLine to have a reference to an object (Product) outside aggregate order?
解决方案I think Customer should have a reference to his orders.
Implementing a relationship with a repository look-up is an alternative to object references. It is useful in these types of situations where there is a relationship between a customer and an order, but it doesn't make sense to implement as object reference. This is so for a few reasons. One is that it may not be feasible to load all orders associated with the customer. Even if lazy loading is used, you typically will want a paginated collection. Another reason is what the author refers to as concurrency conflict detection, which is also referred to as transactional consistency. There aren't any behaviors which involve all orders associated with a customer and referencing all orders is needless.
When get a customer from the database it will not load directly his orders (Lazy Loading). So this is not an argument.
Lazy loading can be problematic. The main reasons are difficultly and lack of flexibility in implementation as well as a reduction in the ability to reason about code.
So what are the real reasons for choosing an aggregate?
An aggregate should be a consistency boundary. In other words, an aggregate delimits a set of entities and value objects which must remain consistent under behaviors corresponding to the aggregate. This has both business and technical ramifications. Take a look at Effective Aggregate Design for more on this.
Why is permitted as OrderLine to have a reference to an object (Product) outside aggregate order?
Typically, an order line should reference a value object representing the ordered product, not a reference to the actual product entity. This is due in part to aggregate constraints discussed, but also because an order is an event and should be immutable.
这篇关于如何选择DDD总结？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
