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);

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?

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

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

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.

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!