Don’t Create Aggregate Roots

Monday, June 29th, 2009.

roots

My previous post on Domain Events left some questions about how aggregate roots should be created unanswered. It would actually be more accurate to say how aggregate roots should *not* be created. It turns out that this is one of the less intuitive parts of domain-driven design and has been the source of many arguments on the matter. Let’s start with the wrong way:

   1:  using (ISession s = sf.OpenSession())

   2:  using (ITransaction tx = s.BeginTransaction())

   3:  {

   4:      Customer c = new Customer();

   5:      c.Name = "udi dahan";

6:

   7:      s.Save(c);

   8:      tx.Commit();

   9:  }

I understand that the code above is representative of how much code is written when using an object-relational mapper. Many would consider this code to follow DDD principles – that Customer is an aggregate root. Unfortunately – that is not the case. The code above is missing the real aggregate root.

There’s also the inevitable question of validation – if the customer object isn’t willing to accept a name with a space in it, should we throw an exception? That would prevent an invalid entity from being saved, which is good. On the other hand, exceptions should be reserved for truly exceptional occurrences. But if we don’t use exceptions, using Domain Events instead, how do we prevent the invalid entity from being saved?

All of these issues are handled auto-magically once we have a true aggregate root.

Always Get An Entity

Let’s start with the technical guidance – always get an entity. At least one. Also, don’t add any objects to the session or unit of work explicitly – rather, have some other already persistent domain entity create the new entity and add it to a collection property.

Looking at the code above, we see that we’re not following the technical guidance.

But the question is, which entity could we possibly get from the database in this case? All we’re doing is adding a customer.

And that’s exactly where the technical guidance leads us to the business analysis that was missing in this scenario…

Business Analysis

Customers don’t just appear out of thin air.

Blindingly obvious – isn’t it.

So why would we technically model our system as if they did? My guess is that we never really thought about it – it wasn’t our job. So here’s the breaking news – if we want to successfully apply DDD we do need to think about it, it is our job.

Going back to the critical business question:

Where do customers come from?

In the real world, they stroll into the store. In our overused e-commerce example, they navigate to our website. New customers that haven’t used our site before don’t have any cookies or anything we can identify them with. They navigate around, browsing, maybe buying something in the end, maybe not.

Yet, the browsing process is interesting in its own right:

Which products did they look at?
Did they use the search feature?
How long did they spend on each page?
Did they scroll down to see the reviews?

If and when they do finally buy something, all that history is important and we’d like to maintain a connection to it.

Actually, even before they buy something, what they put in their cart is the interesting piece. The transition from cart to checkout is another interesting piece. Do they actually complete the checkout process, or do they abandon it midway through?

Add to that when we ask/force them to create a user/login in our system.

Are they actually a customer if they haven’t bought anything?

We’re beginning to get an inkling that almost every activity that results in the creation of an entity or storing of additional information can be traced to a transition from a previous business state.

In any transition, the previous state is the aggregate root.

In the beginning…

Let’s start at the very beginning then – someone came to our site. Either they navigated here from some other web page, they clicked on an email link someone sent them, or they typed in our URL. This can be designed as follows:

   1:  using (ISession s = sf.OpenSession())

   2:  using (ITransaction tx = s.BeginTransaction())

   3:  {

   4:     var referrer = s.Get<Referrer>(msg.URL);

   5:     referrer.BroughtVisitorWithIp(msg.IpAddress);

6:

   7:     tx.Commit();

   8:  }

9:

And our referrer code could look something like this:

   1:  public void BroughtVisitorWithIp(string ipAddress)

   2:  {

   3:     var visitor = new Visitor(ipAddress);

   4:     this.NewVisitors.Add(visitor);

   5:  }

6:

This follows the technical guidance we saw at the beginning.

It also allows us to track which referrer is bringing us which visitors, through tracking those visitors as they become shoppers (by putting stuff in their cart), finally seeing which become customers.

We can solve the situation of not having a referrer by implementing the null object pattern which is well supported by all the standard object-relational mappers these days.

How it works internally

When we call a method on a persistent entity retrieved by the object-relational mapper, and the entity modifies its state like when it adds a new entity to one of its collection properties, when the transaction commits, here’s what happens:

The mapper sees that the persistent entity is dirty, specifically, that its collection property was modified, and notices that there is an object in there that isn’t persistent. At that point, the mapper knows to persist the new entity without us ever having to explicitly tell it to do so. This is sometimes known as “persistence by reachability”.

Where validation happens

Let’s consider the relatively trivial rule that says that a user name can’t contain a space.

Also, keep in mind that a registered user is the result of a transition from a visitor.

Here’s *one* way of doing that:

   1:  public class Visitor

   2:  {

   3:     public void Register(string username, string password)

   4:     {

   5:        if (username.Contains(" "))

   6:        {

   7:           DomainEvents.Raise<UsernameCantContainSpace>();

   8:           return;

   9:        }

10:

  11:        var user = new User(username, password);

  12:        this.RegisteredUser = u;

  13:     }

  14:  }

15:

This actually isn’t representative of most of the rules that will be found in the domain model, but it illustrates a way of preventing an entity from being created without our service layer needing to know anything. All the service layer does is get the visitor object and call the Register method.

Validation of string lengths, data ranges, etc is not domain logic and is best handled elsewhere (and a topic for a different post). The same goes for uniqueness.

Summary

The most important thing to keep in mind is that if your service layer is newing up some entity and saving it – that entity isn’t an aggregate root *in that use case*. As we saw above, in the original creation of the Visitor entity by the Referrer, the visitor class wasn’t the aggregate root. Yet, in the user registration use case, the Visitor entity was the aggregate root.

Aggregate roots aren’t a structural property of the domain model.

And in any case, don’t go saving entities in your service layer – let the domain model manage its own state. The domain model doesn’t need any references to repositories, services, units of work, or anything else to manage its state.

If you do all this, you’ll also be able to harness the technique of fetching strategies to get the best performance out of your domain model by representing your use cases as interfaces on the domain model like IRegisterUsers (implemented by Visitor) and IBringVisitors (implemented by Referrer).

And spending some time on business analysis doesn’t hurt either – unless customers really do fall out of the sky in your world

If you liked this article, you might also like articles in these categories:

DDD | NHibernate | OO | Validation

If you've got a minute, you might enjoy taking a look at some of my best articles.
I've gone through the hundreds of articles I've written over the past 6 years and put together a list of the best ones as ranked by my 5000+ readers.
You won't be disappointed.

If you'd like to get new articles sent to you when they're published, it's easy and free.
Subscribe right here.

Follow me on Twitter @UdiDahan.

Something on your mind? Got a question? I'd be thrilled to hear it.
Leave a comment below or email me, whatever works for you.

72 Comments

Victor Kornov Says:
June 29th, 2009 at 9:45 am
Hello,

“We can solve the situation of not having a referrer by implementing the null object pattern which is well supported by all the standard object-relational mappers these days”

Could you please expand on this? I don’t see how “null object” can help here, as all it does is do not throw error in case of absent referrer. I don’t see how we can actually add an instance of referrer to th DB in the first place. Kind of chicken/egg problem.

Also, NH example in this regard would be greate too.

Josh Says:
June 29th, 2009 at 5:08 pm
I really like this post.. but one question, wouldn’t you start running into an overly large “referrer.NewVisitors” in-memory collection on say the referrer instance from google?

Josh Says:
June 29th, 2009 at 5:47 pm
Victor:
I’d assume he would be using a custom NHibernate Interceptor, overriding the “GetEntity” method, and returning a new instance of the object if the base method returns null. Something like this:

public class MyInterceptor : EmptyInterceptor
{
public override object GetEntity(string entityName, object id)
{
var entity = base.GetEntity(entityName, id);
if(entity == null && string.Equals(entityName, “MyClass”))
return new MyClass((string)id);
else
return entity;
}
}

udidahan Says:
June 29th, 2009 at 10:40 pm
Victor,

See Josh’s comment (#3).

udidahan Says:
June 29th, 2009 at 10:41 pm
Josh,

By mapping the NewVisitors collection as a lazy-loaded bag, you can add to it without incurring a load – so no performance problems there.

Reflective Perspective - Chris Alcock » The Morning Brew #379 Says:
June 30th, 2009 at 12:53 am
[...] Don’t Create Aggregate Roots – Udi Dahan looks at applying (or not applying) agreggate roots in your service layer [...]

Victor Kornov Says:
June 30th, 2009 at 3:41 am
Udi & Josh,

1. Pardon my ignorance but… wouldn’t using intercepter in this manner require you to do a session.Save(referrer) as persitence by reachability won’t work. Referrer isn’t accosiated to any other persistent entity.

2. How do you handle reading from such big collections? IT requires use of session.CreateFilter(…), but session isn’t available to Domain. That means you can’t simply enumerate over e.g. the NewReferrers.

Josh Schwartzberg Says:
June 30th, 2009 at 10:42 am
1. You are correct, this would need to be associated with the current session manually. This should be as easy as calling something like MyStaticSessionManager.CurrentSession.Save(myEntity); before you return it.

2. In a simple scenario, you shouldn’t need to use CreateFilter. As Udi mentioned, setting the NewVisitors collection to a lazy-loaded bag would *not* cause it to load the collection when only an .Add() is performed on it. It would only pull it down if you attempted to enumerate it, which is not done in his example.

In a more complex performance scenario, where a filter is needed since you know you will be iterating the collection, you would simply create a fetching strategy for that particular use case… but this would continue to be something the domain knows nothing about. Udi did a great related presentation about making roles explicit that you can view at http://www.infoq.com/presentations/Making-Roles-Explicit-Udi-Dahan .

Josh Schwartzberg Says:
July 1st, 2009 at 1:02 pm
Watching an even better presentation that shows better examples of performance optimizations @ http://media01.smartcom.no/Microsite/go.aspx?eventid=4486&urlback=null&bitrate=574655

Thanks Udi!

MitchA Says:
July 1st, 2009 at 7:11 pm
Another great post, although I read something near the end that almost made me flinch:

“Validation of string lengths, data ranges, etc is not domain logic and is best handled elsewhere (and a topic for a different post). The same goes for uniqueness.”

This statement runs contrary to most everything I’ve ever read on the subject. Namely, that domain objects ought to provide for their own validity. I’d be very interested to hear your supporting reasons.

-Mitch

udidahan Says:
July 2nd, 2009 at 4:55 am
Mitch,

Domain objects need to maintain their *business validity*. Not accepting dates before today falls under that definition. Strings less than 50 characters in length does not.

Does that make sense?

Graeme Foster Says:
July 3rd, 2009 at 1:15 am
Hi Udi,

It strikes me that this referrers NewVisitor collection is going to get huge (not wanting to analyse up front but lets say google.com!) and ‘adding’ a new entry into it will cause an ORM like nhibernate to fetch the entire collection (based on my rather understanding!)

So is this a case where you might use your DomainEventManager and say void BroughtVisitorWithIP() { … DomainEventManager.Raise(…); }

and then the event handler would sneakily do the ’session.Save(newVisitor)’ stopping the entire collection from being fetched?

Cheers,

Graeme

Graeme Foster Says:
July 3rd, 2009 at 3:59 am
Hi Udi,

Please ignore my earlier comment. I’ve re-read the comments and completely missed the point about the bag mapping not loading the collection in-order to add to it.

Thanks for the excellent postings,

Graeme

Graeme Foster Says:
July 3rd, 2009 at 6:58 am
Hi,

I’ve been trying to get the Null object thing going but am really struggling. I’ve tried using the EmptyInterceptor but find that whilst the 1st time through things are fine and I get a new object, the 2nd time I try to get the same referrer I still get a new object back which blows up when nhibernate tries to insert a dupe key.

The call to base.GetEntity(entityName, id) always returns null so I don’t see how this can work.

Any pointers would be great!

Thanks,
Graeme

Andrew Davey Says:
July 5th, 2009 at 6:28 am
If I make my expand domain to better capture what is happening when creating entities, does this mean my database has to also expand?
For example: Website admin wants to add a new item to the online shop.
I have a ShopItem table.
It seems that “shop.AddItem(name, price, tax, description)” is a reasonable modelling of the situation. However for this to work in an ORM “Shop” needs to exist and have a collection of ShopItems. There is only one shop. So does my database now have an extra Shop table with one row and each ShopItem have a ShopID foreign key?

An alternative could be “admin.AddItemToShop(name, price, tax, description)”, meaning the Admin class now has a ShopItems collection. ShopItems also need an AddedBy foreign key in the database.

Both solutions are workable, but is there another way to approach this?
Or are there any ORMs that let me have transient entities that are not persisted, but still allow persistence of reachable (persistent) children?

Adam Tybor Says:
July 6th, 2009 at 11:36 am
I am really loving this but it breaks down for me in two areas.

1) Having our domain handle the creation and fire the event is really cool but breaks down if the transaction fails. I fire the NewCustomer event but saving that customer failed in the db so many other messages were already sent and actions were taken assuming that a NewCustomer event took place. How do you handle that?

2) What happens when we have really complicated objects to create that require validation and maybe some kind of factory?

visitor.Register(factory, newUserInformation); ???

Gary Brunton Says:
July 10th, 2009 at 10:37 am
Udi,

>Domain objects need to maintain their *business validity*. Not >accepting dates before today falls under that definition. Strings less >than 50 characters in length does not”.

Isn’t the string length rule an invariant of the object in which case it should be handled within the object? If you don’t handle it here are you going to allow this entity to become invalid and then check the validity somewhere else (like in a service)?

I’m really interested in learning how your handling this basic requirement.

Thanks for your insight as this series has been quite enlightening!
Gary Brunton

Jimmy Zimms Says:
July 10th, 2009 at 12:34 pm
Hey Udi,

That pic of the roots in the header: Perchance is that from the allerton garden in Kauai? Just did a double take and realized that looks like the 3 massive eucalyptus trees (the same ones used in Jurassic park) along the Lawaʻi river. Anwyays… cheers

Evgeny Shapiro Says:
July 12th, 2009 at 11:08 am
Adam,

Consistency is maintained through local distributed transaction which covers sending messages through MSMQ and Database interaction. All the messages will be sent only on transaction commit.

Evgeny Shapiro Says:
July 12th, 2009 at 11:11 am
Adam,

Actually MSMQ is not a requirement local distributed transaction is an approach independent from technology.

udidahan Says:
July 12th, 2009 at 11:21 am
Jimmy,

Google images just found me something I liked – nothing more to it than that

udidahan Says:
July 12th, 2009 at 11:23 am
Evgney – good answer to Adam.

udidahan Says:
July 12th, 2009 at 11:27 am
Adam,

To your second question about complex object creation and/or validation, what I’ve usually found in those cases is that this is a by-product of trying to take something inherently statefull and make it stateless.

If you were to create the object earlier in some kind of “tentative” state where little validation was required, and then manage each state transition with the specific bits of validation needed, I think that many of the issues you’re running into will dissolve.

Does that answer your question?

udidahan Says:
July 12th, 2009 at 11:36 am
Andrew,

Given the description of the requirement, it sounds like the website admin is your aggregate root like you mentioned:

admin.AddItemToShop(name, price, tax, description);

However, you don’t necessarily need to have a ShopItems collection. I’d prefer: AddedShopItems

And to the database part of the question, you can set up views on top of your table and use the ORM to map to those. On the views, set up INSTEAD OF triggers to move the data to the appropriate table. Or, you could use a different persistence mechanism than a relational DB.

Does that help?

udidahan Says:
July 12th, 2009 at 11:39 am
Graeme,

You may need to go lower than the EmptyInterceptor and write your own Entity Persister overriding some of the basic behaviors.

This case is one of the edge cases of the domain/solution. In many scenarios you can ensure that you’ll always have an Id of an existing entity to come in on.

Hope that helps.

Gilligan Says:
July 14th, 2009 at 11:44 am
Do similar guidelines apply when deleting entities in the domain?
Would you do something like Visitor.UnregisterUser() or User.Unregister() (with an internal call to Visitor.UnregisterUser() if it is bidirectional)?

udidahan Says:
July 15th, 2009 at 12:39 am
Gilligan,

Rarely should entities actually be technically deleted, if ever. The better option is to change some kind of status on the entity.

In your example, there is business value in tracking who unregistered, what was their history, do we find that users who unregister have something similar in their history, etc.

Hope that makes sense.

Jørn Wildt Says:
July 24th, 2009 at 12:41 pm
Udi wrote:
> The most important thing to keep in mind is that if your service
> layer is newing up some entity and saving it – that entity isn’t
> an aggregate root *in that use case*

I have always thought of aggregates as being static. You have an aggregate root with an identity you can lookup and from this you can access parts of the aggregate. A part of the aggregate always have the same aggregate root – it cannot belong to another aggregate.

So why are you stressing “that entity isn’t an aggregate root *in that use case*”? Does an aggregate root depend on the use case? So an object is an AR in one case, but not in another case?

/Jørn

udidahan Says:
July 25th, 2009 at 4:27 am
Jørn,

> So why are you stressing “that entity isn’t an aggregate root *in that use case*”?

To get you to ask your next questions:

> Does an aggregate root depend on the use case?

Yes.

> So an object is an AR in one case, but not in another case?

Yes – an object can be an AR in one use case, but not another.

> I have always thought of aggregates as being static.

I know – it’s intuitive, but wrong

> A part of the aggregate always have the same aggregate root – it cannot belong to another aggregate.

What value does that bring you?

> You have an aggregate root with an identity you can lookup

Which you can do in either model.

> you can access parts of the aggregate

That’s just it – from outside the domain model, nobody should be accessing parts of an aggregate. Remember that querying for the purposes of showing data to the user is done by something other than the domain model – according to CQS principles.

Hope that makes sense.

Vincent Partington Says:
July 25th, 2009 at 7:36 am
Udi,

While I appreciate the architectural cleanness of this approach, I doubt you will be able to achieve good performance when the object graph gets complex and the collections get large.

In fact I also prefer to let the ORM provider handle this (to let the persist operation cascade in JPA terms), but performance has forced me to rethink that in some cases. See my blog on some the performance issues that can be encountered when relying too much on the laziness of collections:
http://blog.xebia.com/2009/05/25/jpa-implementation-patterns-bidirectional-associations-vs-lazy-loading/

Vincent.

Nuz Says:
July 26th, 2009 at 7:07 am
Hi Udi,

If a customer is a root aggregate and address is a value object in my context. I would want to show a dropdown list of all the States on my UI as the user is entering information.

How would I handle the states object? Since it is not a root object. Would I create a repository for the State items? Since I will need to manage them from an admin screen. I.E initially when the app goes online, add the states to the table, instead of going directly to the database state table and populating directly from sql server studio management ui.

Thanks

Jørn Wildt Says:
July 26th, 2009 at 12:57 pm
> > A part of the aggregate always have the same aggregate root – it cannot belong to another aggregate.
> What value does that bring you?

According to Eric Evans book ARs define explicit boundaries for consistency – an aggregate defines where one object graph begins and ends. So I cannot see why different use cases should lead to different ARs – then you would get your object graphs all messed up.

Lets take Eric’s example of a car having a wheel and tires – the car is the AR and the wheel and tires are part of the aggregate. What you are saying is that when I am buying a case (use case 1) then the car is the AR – but when I am selling it, something different is the AR for the wheel and tires?

I don’t get it …

/Jørn

Ryan Riley Says:
July 28th, 2009 at 2:43 pm
This question seems so different from the others that I think I already know I am wrong, but I have to ask. Are you saying an Aggregate Root should basically be a state machine? The more I think about it, the more I like it, especially from a CQS perspective.

In relation to the lazy-loaded entity bag, why would you have a bag at all? Do you really need that collection to add and remove items? Why can’t Add() and Remove() be methods that send messages?

Finally, Nuz asked about listing states in a drop-down, which all the more makes me think that the Aggregate Root-as-state-machine is where you were headed, as it’s a much better idea than CRUD-ish user selection of state (if I read his question right).

udidahan Says:
August 1st, 2009 at 1:25 am
Vincent,

If large collections are a problem, it is often an indication that the domain model needs to be restructured a bit to deal with only the elements relevant to the given use cases. Sometimes this can be done by mapping to DB views, sometimes even having triggers on them for pushing data back to the source tables.

udidahan Says:
August 1st, 2009 at 1:26 am
Nuz,

Showing information in the UI should not be done off the back of domain model objects – see my posts on command/query separation.

Hope that helps.

udidahan Says:
August 1st, 2009 at 1:28 am
Jørn,

Consistency is only interesting in the context of a use case, not in some global/absolute sense. If all use cases are consistent all the time, what else do you need?

udidahan Says:
August 1st, 2009 at 1:33 am
Ryan,

While abstractly one could look at a domain model changing its state as a result of commands and see state machine style behavior there, I’m not sure how useful it is at the practical level, especially as you get more bounded contexts which prevent the complexity of a given domain model from growing too large.

The reason you don’t want to model adds (not removes) from a bag as messages as you’d want full transactional consistency around everything.

As for Nuz’s question, see my response above.

Thanks.

Fluent Domain Methods | Elegant Code Says:
August 1st, 2009 at 12:59 pm
[...] This means that the aggregate root is responsible for creating instances of a Tag (also check out this post from Udi [...]

JDT's Blog » Ubiquitous language: what is so blindingly obvious you can’t see it? Says:
August 7th, 2009 at 1:42 pm
[...] order to see them. Udi Dahan helped me take that step back some time ago with his article ‘Don’t create aggregate roots‘. While I agree with him on most of what he details in his post, I feel that something is [...]

Joe Says:
August 11th, 2009 at 1:24 pm
It seems like the idea of never directly creating aggregate roots breaks down when doing event sourcing.

Here’s my dilemma. If events are persisted for aggregate roots (all events from the aggregate) but the aggregate root is also treated as a plain old entity in another aggregate then both aggregate roots must have the same events stored for them in order to be replayed from persistence. One set of events is necessary to replay the aggregate root which has the 1st aggregate root as an entity and another set of events is necessary to replay the entity when viewed as an aggregate root.

I think the problem is that the guidance which indicates that aggregates should be consistency boundaries for transactions makes it impossible for something in an aggregate to hold anything but the id of an aggregate root from another aggregate.

Please correct me if I’m wrong in any way but it seems like aggregate roots should stand alone and not be viewed as plain old entities.

udidahan Says:
August 12th, 2009 at 7:54 am
Joe,

I haven’t tried this style when using event/command streams as the persistent state of an aggregate so wouldn’t know what to answer. Greg and I have had some conversations on the topic but haven’t reached a consistent style that fits both yet.

When we do eventually come up with one, don’t worry, we’ll both blog about it.

Mike Scott Says:
August 25th, 2009 at 5:25 am
Hi Udi

Converting a referrer->visitor->user on a web page is a clear example of not creating an aggregate root because there are pre-existing entities with life cycles which culminate in the creation of a user entity.

However, what about the general case where you’re entering some other data into a system where there is no pre-existing entity? For example, in a property letting system, a landlord walks off the street into your office and asks for you to market his property.

Since he’s a new landlord not already on the system, you have to enter him for the first time. You also have to enter the property. So, leaving aside the question of which you’d enter first, what is the initial aggregate root? Are you suggesting that the logged in user who deals with the landlord is the root? That the user aggregate should have a Landlords collection and the landlord should be added to that?

And to the second question, should either the landlord or the property be entered first and become the aggregate root to which the other is added, as in your example of jobs and job boards? Or should both be added to respective Landlords and Properties collections on the user aggregate?

I’m enjoying the challenge of your “don’t create aggregate roots” assertion. It requires a major reshuffle of common practice & habits and some deeper thinking of the domain and DDD, which is a good thing! Please keep these posts coming!

udidahan Says:
August 25th, 2009 at 1:54 pm
Mike,

Sounds like you’re pointed in the right direction. The user who enters the landlord could be aggregate root. Or you might ask him if he saw an ad and that caused him to come in – in which case the ad would be the root.

My feeling would be the landlord would come first, and then the property.

Glad you’re finding this approach useful.

Mike Scott Says:
August 25th, 2009 at 3:08 pm
Udi,

Thanks, so the landlord would be entered as a part of the user or ad, and then the property as part of the landlord? Why not both as part of the user? Is that equally possible or is there a reason for not doing that?

Also, there has to be one FIRST root, right?

Finally, been re-reading Evans after digesting this post… He recommends creating aggregate roots using factories mainly, either classes or factory methods, or even just plain newing up an object if it’s a trivial case. Just to clarify, are there any cases where you’d recommend creating an aggregate root or do you always recommend creating them by adding to an existing entity?

Your technique is very organic – it reminds me of biogenesis, i.e. that life always spawns from previous life, that it never happens spontaneously, except at the very beginning… Perhaps biogenesis could be a good name for this DDD principle

udidahan Says:
August 25th, 2009 at 11:40 pm
Mike,

The method on the previous entity can be viewed as the factory method of the new aggregate root. My recommendation is that if you’re using the domain model pattern (not a foregone conclusion) you use this biogenetic approach (not a bad name).

Gilligan Says:
September 3rd, 2009 at 8:00 am
I find myself in a lot of cases where the business model does not explicitly create entities, but will either pull an existing entity or create a new one. Example, the first time a user wants to place an item in the cart, there is no explicit “Create cart” process because we do not know whether or not we need a cart until a user adds an item to it or wants to view if anything is in their cart. Does it make sense in these cases to view the aggregate root also as a repository as well as a factory, where it simply searches its collection and if the cart does not exist it creates one? (this is what I currently do)

udidahan Says:
September 3rd, 2009 at 11:44 pm
Gilligan,

I’m not sure I understand you fully.
If you’re calling a method on your User object like PlaceItemInBasket(item), and it internally checks for the existence of a Cart object, creating it if it isn’t there, I’d say that that’s OK. However, it’s not really repository behavior since the Cart object would be designed as a property of the User object, though you could say it does serve as a factory.

Does that answer your question?

Gilligan Says:
September 4th, 2009 at 5:09 am
I think my situation may not be appropriate domain driven behavior.
It is more like this: a cart’s identity is determined by two properties: the current ordering program and the current user. So I will first get the program, then call a method program.GetCartForUser(user). This method will either create a new cart or retrieve an existing one. Then I will call cart.AddItem(item, quantity).

udidahan Says:
September 5th, 2009 at 8:06 am
Gilligan,

Could you not do:

user.AddItemToCartForProgram(program, item, quantity);

Mike Scott Says:
September 16th, 2009 at 9:23 am
Udi,

Regarding #49, could you expand on how you’d implement user.AddItemToCartForProgram(program, item, quantity)?

Gilligan says he needs to check if a cart exists and create one if not. Where and how would this check be done? It seems to be cascading the lookup. In your original example, the service layer asks the ORM/repository to get a referrer. This is cool in the service layer, but in AddItemToCartForProgram, the domain object would have to do that for the cart, no?

I’d love to see your general solution to this type of behaviour

udidahan Says:
September 17th, 2009 at 11:36 am
Mike,

The user object would have a reference to its cart object – check if its null, if so, create a new one, set the reference. The ORM would do the dirty tracking on the user object and know to persist the new cart / the modified old cart.

Does that answer your question?

Mike Scott Says:
September 19th, 2009 at 6:45 pm
Hi Udi

So if I’m following you correctly, the user would be the aggregate root and the user repository would built the aggregate, assigning the cart if one existed already or leaving it null if not.

Then, in the user class’ domain logic, there would be code to create a new cart if it was null and this would be persisted by reachability?

If so, I can see that the code to deal with the cart is in the repository if one exists, and in the domain object if not. The usual way of handling this would be to have the load/check and creation together in the same piece of code, though your suggestion seems reasonable

udidahan Says:
September 19th, 2009 at 11:47 pm
Mike,

The repository in this case would need to be nothing more than a regular ORM that eagerly fetched the cart object (if there was one) along with the user object. You don’t need a custom repository for this.

The same thing goes for “persistence by reachability”, since the user object gets dirty, the ORM knows to persist it and the objects connected to it.

Hope that makes sense.

Mike Scott Says:
September 20th, 2009 at 3:29 pm
Sure, understand perfectly. But that leads to the next question

Unit testing! How do you unit test the code that depends on the ORM? Do you abstract it?

udidahan Says:
September 21st, 2009 at 12:21 pm
Mike,

The only code that depends on the ORM is the service layer. The domain model doesn’t depend on anything other than itself – and it’s the thing you’ll be unit testing.

Does that make sense?

Mike Scott Says:
September 24th, 2009 at 9:53 am
Hi Udi

It makes sense to test the domain model, of course, but it also makes sense to test the service layer to make sure it is orchestrating things correctly, no?

udidahan Says:
September 24th, 2009 at 2:26 pm
Mike,

The service layer shouldn’t orchestrate – after getting a domain object or two, it calls a single method on one of them, that’s it.

See my High Performance Domain Models presentation.

Jørn Wildt Says:
September 25th, 2009 at 12:25 pm
Udi, is it this your are talking about: http://www.udidahan.com/2007/10/26/teched-speaking-about-high-performance-persistent-domain-models/ when you say High Performance Domain Models presentation?

The links on that page are not alive anymore

Can it be found elsewhere?

Mike Scott Says:
September 29th, 2009 at 8:44 am
Udi

I understand that the service layer only makes a single call into the domain layer, but I’m still not convinced that it’s not doing enough orchestrating that it doesn’t need unit testing. It has to work with the persistence layer as well as calling into the domain.

However, I do see your pont that if you have NHibernate code creating a session and a transaction in the session layer, that you could just forego abstracting your persistence, ignore unit testing and rely on integration tests.

Is this what you’re advocating?

udidahan Says:
October 4th, 2009 at 2:48 am
Jørn,

Check out this link as well:

http://www.udidahan.com/2008/02/15/from-crud-to-domain-driven-fluency/

udidahan Says:
October 4th, 2009 at 2:51 am
Mike,

You bring up the point exactly:

“It has to work with the persistence layer as well as calling into the domain”

Would a unit test that mocks out the persistence layer give us much more confidence in the correctness of the code? So much so that we didn’t need the integration test? And if we do go and put an integration test in place, what incremental value does the unit test provide? Does it, in essence, assert that the code is implemented the way it’s implemented?

Hope that makes sense.

Mike Scott Says:
October 8th, 2009 at 5:35 am
Hi Udi,

“Would a unit test that mocks out the persistence layer give us much more confidence in the correctness of the code?”

Yes, I believe it would. I think the service code should be unit-tested as well, even though it’s simple. Any breaking changes will be detected in seconds, rather than waiting for them to fail in the integration tests and be more difficult to track down later.

If you take your argument to its logical conclusion, we could do away with unit tests altogether and rely solely on automated integration testing, could we not?

There’s also the issue of using unit testing – or better to say specifying – first in order to create more expressive interfaces.

udidahan Says:
October 8th, 2009 at 9:15 am
Well Mike,

Then we can agree to disagree

Richard Dingwall » Life inside an Aggregate Root, part 2 Says:
October 13th, 2009 at 12:31 pm
[...] The new keyword is a bit of a smell here — as Udi Dahan recently stated in a blog post, customers don’t just appear out of thin air. Let’s flip it [...]

Jon Says:
February 18th, 2010 at 1:48 pm
Hi Udi,

I really like the idea of persistence by reachability. However, I’m trying to implement this using NHibernate and I’ve run into a problem with many to many relationships. How do you avoid loading up the entire collection when adding to it?

Thanks,
Jon

Strengthening your domain: Aggregate Construction - Jimmy Bogard - Los Techies : Blogs about software and anything tech! Says:
February 23rd, 2010 at 10:12 pm
[...] Through existing aggregate roots [...]

ryzam Says:
April 23rd, 2010 at 5:21 pm
Hi Udi, your case is for newly customer, but how about existing customer. For me an existing customer can be right candidate to act as an AggregateRoot.

From general perspective, I see role archetype (peter coad) by default can be an AggregateRoot

udidahan Says:
April 24th, 2010 at 5:14 am
Ryzam,

Well, an existing customer may be an Aggregate Root for certain use cases in a given bounded context.

Jørn Wildt Says:
April 26th, 2010 at 2:36 pm
Hi Udi

There’s a thing that bothers me here. Others have mentioned it already: the size of the collection. Not only the initial collection – but the complete object graph that results from this line of thinking.

Let’s assume we have a Website with blogs with posts with comments. Following the above principle, we add blogs through websites, posts through blogs, and comments through posts.

This means the root object, the Website, ends up containing a massive object graph where all possible content items on the website are reachable from the Website root. Is this really the intention?

It also makes it difficult to implement a content plugin structure since the Website has to know all possible content types at compile time in order to create the AddBlog, AddArticle, AddPhoto, AddUser etc. methods. This is probably not your intention, so what am I missing?

/Jørn

udidahan Says:
April 27th, 2010 at 12:54 pm
Jørn,

First of all, aggregate roots (AR) are used on the command side of CQRS and not the query side, in which case theoretical reachability on the command side is less relevant.

Second, an AR is only relevant for scenarios where we’re using a domain model – if the action is a simple insert operation, we can do that without using the domain model. Not all commands need to involve the same domain model.

I’m pretty sure that that leaves you with more questions – but the answers to those questions ultimately are project-specific. These patterns are to help you know which questions to ask – not to provide you with answers

Lionel Orellana Says:
July 9th, 2010 at 6:38 pm
Hi Udi,

I’ve gone through previous comments and couldn’t see the point of bi-directional associations being raised directly. Your approach will create a lot more bi-directional associations than are otherwise needed. I don’t think I’m taking Evans too literally when I say bi-directional associations are best avoided. From the DDD bible:

“In real life, there are lots of many-to-many associations, and a great number are naturally bidirectional. The same tends to be true of early forms of a model as we brainstorm and explore the domain. But these general associations complicate implementation and maintenance. Furthermore, they communicate very little about the nature of the
relationship”.

Cheers,

Lionel.

udidahan Says:
July 11th, 2010 at 3:50 pm
Lionel,

I agree that we don’t want many (any) bi-directional associations when using the domain model pattern. Don’t take the guidance given in this article as being complete – it is here to illustrate a very specific part of a more comprehensive set of techniques.

Also, see my more recent posts talking about how the domain model pattern shouldn’t necessarily be used for all “business logic” and definitely not for the purposes of all persistence.

Kind regards.