DDD应用到Northwind数据库 [英] Applying DDD to Northwind database

问题描述

我想做些exercice和应用DDD我的应用到Northwind数据库域模型。即使罗斯文是一个例子，我想象它是为了满足一些虚拟经营的要求。因此我们的目标是有尊重DDD域模型和数据存储在数据库Northiwnd

考虑这个EF持久化模型：

请注意，我们只有在实体和双向关系。我想有尊重DDD一个真正的DM。更多的，我的DM模型并不需要是我的数据库的镜像

1. 你会怎样改变需要时德关系只有一条路的关系，或两种方式。




2. 是否有任何多到一或一到多的关系，可以改为一对一？




3. 你会如何建模agregates？




4. 怎么样值的对象，服务和工厂如果需要的话？

我知道，可能是我建议立即进行删除一下的业务需求，看起来模型应该怎么改变，但想听听您对那advaice。

不要犹豫，询问细节，如果我的问题不明确。

先谢谢了。

解决方案

在一般我很想回答穆（在禅意），因为该方案是从DDD观点是错误的。在DDD，我们开始与业务需求和领域专家，并从这些我们得出一个域模型

虽然这是一个有争议的问题，数据库的业务需求几乎只是一个偶然的工件（即几乎总是指出，实体必须被持久化）。

这是说，我会尽力做到最好。

在大多数情况下，订单是pretty重要的业务对象，很显然，我们需要了解的命令行，包括每条线的产品，所以它看起来像我们需要从订单行协会（ Order_Detail）产品。

不过，由于特定的产品时，我们很少需要知道哪些订单它被列入，使提出的单向关系就在那里。我们可以从订单行产品的导航，而不是从产品到订单行。

不过，上述分析可能会变成是一个更深层次假的。想象一下，开发商和领域专家之间的对话如下：

开发： 我们已经创建了该协会从接单到产品使我们始终了解产品中的特定顺序的一切的

工作经验： 这听起来不错，但对于供应商的

？

开发： 这也包括在内的

。

工作经验：当我们改变供应商对产品的会发生什么的

开发： 这将隐含反映在订单数据以及... 的

工作经验： 这不是我们想要的。我们希望这些数据以反映在我们推出它的时候的顺序。的

在这种情况下，事实证明确实有在数据库模式的错误。该问题可能是由报告引起的，因为企业analysists可能需要运行在不同如何影响供应商的财报（我知道什么）。

这样的情况可能会建议从订单线切割关联产品一共。订单应持有历史（快照）产品数据，不是当前的产品数据。

我们甚至可以entroduce一个 ProductSnapshot 值对象的语义反映一个产品 < STRONG>实体的域模型来模拟这一点。

所有的一切，似乎更多，更合理的模型订单为本身和订单行（合计与 ProductSnapShots ），但对于订单和客户之间的关系？

据我了解目前协会和聚集，协会定义聚集。给定一个订单，我们想了解的客户？最有可能的。给定一个客户，你想知道的命令？也许吧。

这表明一个双向关系，这使客户在聚合根。这意味着你将有一个 CustomerRepository ，但没有 OrderRepository 。每当你需要一个订单时，都必须通过客户得到它。

在某些情况下，这可能使完美的意义，而这可能是在其他情况下，实际上笨重。这真的取决于业务需求...

您可以考虑创建一个 OrderRepository 为好，但侵入客户聚合根。如果你这样做，它变得含糊其中用于秩序的责任所在。如果你从nagigate为了客户，会发生什么？ 客户有订单的列表，但他们都在内存中填充，如果你阅读的顺序 OrderRepository <？ / p>

或许不会，但他们很可能是如果你读从 CustomerRepository 客户。这里的要点是的总根的分析是非常重要的，一旦你已经定义了一个总结，你将不得不坚持下来并尊重它。

这使我的青睐小聚集过大聚集，因此，在这个例子中，我总限制为订单及其订单行，并有订单和客户。

之间没有关联

由于没有订单之间的正式关联和客户并不意味着我们不能在他们的关系所有的，但我们需要明确的服务，以使我们所有的订单对于给定的客户。我们不能只从一个到另一个导航。

I would like to do some exercice and apply DDD to my Domain Model applied to Northwind database. Even if Northwind is an example I imagine that it was done to satisfy some " virtual business" requirements. So the goal is to have a Domain Model that respects DDD and the data is stored in Northiwnd database.

Consider this EF persistance model :

Notice that we have only the entities and two way relations. I would like to have a real DM which respects DDD. More, my DM model doesn't need to be the mirror of my database

1. How you would change des relations to have only one way relations or two ways when needed.

2. Are there any many-to-one or one-to-many relations that could be changed to one to one?

3. How would you model agregates ?

4. How about Values Objects, services and factories if needed ?

I know that probably I shoul look at business requirements and that look how the model should change but would like to have your advaice on that.

Don't hesitate to ask for details if my question is not clear.

Thanks in advance.

解决方案

In general I'm tempted to answer Mu (in the Zen sense), because the scenario is wrong from a DDD perspective. In DDD we start with business requirements and Domain experts and from those we derive a Domain Model.

Although it's a controversial point, the database is almost just an incidental artifact of the business requirements (that almost always state that Entities must be persisted).

That said, I'll try to do my best.

In most cases, an Order is a pretty important business object, and obviously we need to know about the order lines, including the Products in each line, so it would seem like we need the association from order line (Order_Detail) to Product.

However, when given a particular product, we rarely need to know in which orders it was included, so that suggests a one-way relationship right there. We can navigate from order line to product, but not from product to order lines.

However, the above analysis may turn out to be false on a deeper level. Imagine the following conversation between the developer and the domain expert:

Dev: We've created this association from orders to products so that we always know everything about the products in a particular order.

Exp: That sounds good, but what about the supplier?

Dev: That is included as well.

Exp: So what happens when we change the supplier for the product?

Dev: That will be implicitly reflected in the order data as well...

Exp: That's not what we want. We want the data to reflect the order at the time we shipped it.

In this case, it turns out that there's actually an error in the database schema. The problem may be caused by reporting, because business analysists may want to run reports on how different suppliers impact earnings (what do I know).

Such a case may suggest cutting the association from order lines to product altogether. Orders should hold historic (snapshot) product data, not current product data.

We may even entroduce a ProductSnapshot Value Object that semantically mirrors a Product Entity to model this in the Domain Model.

All in all, it seems more and more reasonable to model Order as an aggregate of itself and order lines (with ProductSnapShots), but what about the relationship between orders and customers?

As I currently understand associations and aggregates, associations define aggregates. Given an order, would we like to know about the customer? Most likely. Given a customer, would you like to know about the orders? Probably.

This suggests a two-way relationship, which makes Customer the Aggregate Root. This means that you would have a CustomerRepository, but no OrderRepository. Every time you need an Order, you must get it via a Customer.

In some cases this may make perfect sense, while this could be really clunky in other situations. It really depends on the business requirements...

You might consider creating an OrderRepository as well, but that invades the Customer Aggregate Root. If you do that, it becomes vague where the responsibility for the Order lies. What happens if you nagigate from Order to Customer? Customer has a list of Orders, but are they all populated in memory if you read the Order from the OrderRepository?

Probably not, but they are likely to be if you read the Customer from the CustomerRepository. The point here is that analysis of Aggregate Roots is important, and once you have defined an Aggregate, you will have to stick with it and respect it.

That causes me to favor small aggregates over big aggregates, so in this example, I would constrain the aggregate to Order and its order lines, and have no association between Order and Customer.

Not having a formal association between Order and Customer doesn't mean that we can't relate them at all, but we need explicit services to gives us all Orders for a given Customer. We can't just navigate from one to the other.

这篇关于DDD应用到Northwind数据库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！