Aggregate Roots DDD/UoW/Repo/Service

Question

I have some questions about the Aggregate Objects for Repositories.

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.

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.

Let's say I have these entities :

• Customer
• Order
• OrderLine
• Article

D atabase Relationsships :

• A customer can have many orders.

• An Order can only have one customer.

• An Order can have many OrderLine's.

• An OrderLine can have one Article.

Questions :

• Are all of these aggregates except Article?

• And which of these Entities would have a repository?

• What would the repository look like?

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

Thanks in advance.

Answer 1

1. 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. Eg In some system, the Customer could be an aggregate and Order just an entity and in some other backward. This decision should be made by an architect.

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 eg 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.