5

Based on the following definitions from Domain-Driven Design: Tackling Complexity in the Heart of Software,

An aggregate is: A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the AGGREGATE, designated as the root. A set of consistency rules applies within the AGGREGATE'S boundaries.

I don't think the Aggregate root should hold a reference to the repository. Since the Aggregate root is the only one that should be holding references to its entities and aggregates, they should be private.

How can my repository persist and restore this private data ?

Edit:

Let's take the classic Order, OrderLines example.

An order is the Aggregate root.

It's lines are Entities.

Since the Aggregate root(order) is the only object allowed to hold references to its entities (order lines), I do not understand how would I persist order lines from the repository.

Martin
  • 5,954
  • 5
  • 30
  • 46
  • What do you use as your data access strategy? ORM, CQRS, ...? – Filip Zawada Feb 28 '11 at 19:57
  • Well, possibly ORM, but I am not sure. I am new to DDD and my concerns are more about the fact that if the Aggregate root doesn't expose its entities, I won't be able to persist them. – Martin Feb 28 '11 at 20:24
  • Your question seems, at first glance, asking about a specific implementation of the repository and language. Can you be more specific? For example, are you using .NET or Java or something else? Are you planning on using Hibernate or Entity Framework or the built-in ORM in RoR? – Matthew Bonig Aug 10 '11 at 03:27
  • ORM frameworks use reflection to inspect the aggregate structure and extract a database-friendly datas structure. Repository interface should know nothing about what there is inside an aggregate, but the repository implementation cannot get along to know it,,, it's reasonable and factories don't come into play, since a factory is used to build an aggregate that doesn't exists yet and probably will be subsequently persisted – Carmine Ingaldi Nov 03 '19 at 10:24

2 Answers2

5

As far as I understand the aggregate root, it must be the place to access all the entities inside it's scope. That means, as long as traditional ORM is used, that you can access the OrderLines throug the Order.

Further it is not forbidden for anyone to grab a reference to the entitiy inside the root, but these references must be volatile (i.e. short lived) and you must obtain the rerefence via the aggregate root.

In terms of DDD you will use a repository to hide data access, the factory might in turn use a factory to assemble the object. The facotry knows well about the internal structure of the object and must be able to build up a new object or restore one from the data the repository hands over.

Perhaps you might also look into CQRS + Event Sourcing which provides a different approach to persisting entities.

Tobias
  • 116
  • 1
  • 4
  • I agree, I don't see much purpose in not exposing these objects. Validity is maintained by the AR in my opinion. – Matthew Bonig Aug 10 '11 at 03:25
  • CQRS/ES does exactly the same things that a CRUD application does until the domain layer. The way aggregates are persisted is hidden to the client code, but you can still access them through repositories – Carmine Ingaldi Nov 03 '19 at 10:19
0

Well, most folks consider the repository to be a logical feature of hte aggregate root (since there's only one per aggregate, in traditional DDD), so it does & should have access to the orderlines.

If you really want them to be private, though, you would need to resort to reflection, or else have the aggregate root entity return them in some persistable fashion (perhaps w/ an internal call of some kind).

Paul
  • 35,689
  • 11
  • 93
  • 122