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.

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.

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

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

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

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

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

Then we can agree to disagree

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

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.

Check out this link as well:

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

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?

The links on that page are not alive anymore

Can it be found elsewhere?

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.

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?

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?

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

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.

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

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?

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

Could you not do:

user.AddItemToCartForProgram(program, item, quantity);