汇总根DDD / UoW /回购/服务 [英] Aggregate Roots DDD/UoW/Repo/Service

问题描述

我对存储库的聚合对象有一些疑问。

I have some questions about the Aggregate Objects for Repositories.

我正在使用DDD / UoW / Repo和Service模式进行Rest Service。我们新的云Web应用程序将使用此服务。为此，我们还必须同步仍在生产中的旧数据库中的数据。我们创建了一个 SyncService，可以读写云中的数据，甚至可以读写到地球。

I'm making a Rest Service with DDD/UoW/Repo and Service pattern. Our new cloud web-apps shall use this service. In order to do this, we also have to sync data from the old databases, which are still in production. We created a "SyncService" which read and writes to/from the cloud and down to earth.

在我的Rest / DDD设计中。而且我不希望在这些基础上运行业务逻辑，因此在原始测试项目中，我为每个模型都有一个存储库，并且端点只需进行一些简单的验证，然后使用该存储库将数据直接推送到数据库。

In my Rest/DDD-design. And I don't want the business logic to run on these, so in the original test project I have a repository for every model and the endpoints just do some simple validation and push the data straight to the database using the repository.

假设我有这些实体：

• 客户


• 订单


• OrderLine


• 商品

• Customer
• Order
• OrderLine
• Article

D 数据库管理关系：

• 客户可以有很多订单。

• A customer can have many orders.

一个订单只能有一个客户。

An Order can only have one customer.

一个订单可以有多个OrderLine 。

An Order can have many OrderLine's.

一条订单行可以有一条商品。

An OrderLine can have one Article.

问题：

• 除 Article外，是否所有这些汇总？

• Are all of these aggregates except Article?

以及这些实体中的哪个实体将具有存储库？

And which of these Entities would have a repository?

存储库的外观如何？

What would the repository look like?

我是否应该使 SyncService的端点仅与通用存储库对话以进行插入？

Should I make endpoints for the "SyncService" to only talk to generic repositories for insertion?

预先感谢。

推荐答案

除了Article以外，所有这些汇总都是吗？

Are all of these aggregates except Article?

我认为，如果不访问业务逻辑并了解整个域的外观，就不可能回答这个问题。例如。在某些系统中，客户可以是一个集合，而订单可以是一个实体，而在其他方面则可以。
此决定应由建筑师做出。

I believe it's impossible to answer this question without having access to the business logic and understanding how the whole Domain should look like. E.g. In some system, the Customercould be an aggregate and Order just an entity and in some other backward. This decision should be made by an architect.

2,3,4。如果您使用DDD，则可以通过汇总访问实体。我想说使用存储库模式的概念是可选的。在某些情况下，您可以只使用纯数据库上下文，例如例如，如果您使用的是Entity Framework Core，则不必在其之上构建额外的存储库层，因为它本身已经是一个存储库。因此，这些问题的答案将是-取决于一切。

2,3,4. If you are using DDD you access your entities by your aggregates. I'd say the concept of using the repository pattern is optional. In some cases, you can just use pure DB context and e.g. if you are using for example Entity Framework Core you don't have to build extra repository layer over it as it is already a repository by itself. So the answer to these questions would be- it all depends.

这篇关于汇总根DDD / UoW /回购/服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！