Ayende @ Rahien

Ayende Rahien commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Sun, 12 Jul 2009 08:24:09 GMT

Colin, That is part of DDD anyway

Colin Jack commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Sun, 12 Jul 2009 08:22:25 GMT

"The association between a contained entity and its aggregate must be direct. That is, any contained entity must have a direct reference to its aggregate, not going via intermediaries." This would be the bit I've been unhappy with when considering this sort of solution in the end.

Ayende Rahien commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Sat, 13 Jun 2009 15:15:21 GMT

Value objects are part of the entity as far as NH is concerened

s_tristan commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Fri, 12 Jun 2009 09:40:06 GMT

I resolved the problem by defining two custom collections: 1. ManyToOneCollection 2. ManyToManyCollection This collections automatically manages the relationships on both sides.

Peter Morris commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Fri, 12 Jun 2009 08:34:30 GMT

In my opinion there are two parts to the "Aggregate root" pattern, which really should be two different patterns. Part 1: Lifetime management. An OrderLine is part of an Order, so it must live and die as a composite part of that Order. Part 2: Validation When updating an OrderLine you must validate via the Order so that you can check validation as a whole. Such as "Is the total order value < 1000" etc. NH already handles part 1 quite nicely so I won't bother mentioning it any further. This post is attempting to address Part 2, however it is too simple to work. The "validation root" depends entirely on what you are doing. Example 1: Raising a new order Requirement: I need to ensure that the total value of unpaid orders for the customer does not exceed the customer's credit limit. DDD solution: You ensure a version upgrade is performed on Customer. Example 2: Creating a shipping document from an Order Requirement: The order is only considered closed for modification once a shipping order has been completed. When creating the shipping document from the Order we need to ensure that it accurately represents the content of the Order. DDD solution: Ensure a version upgrade on Order when creating a shipping document for it. There is no need to do a lock on Customer because we are not changing the value of the order, nor are we adjusting the Customer's outstanding balance. So here you see we have 2 different operations on an Order which both require a different "validation root". Personally I think the DDD agg-root pattern is a mix of two different patterns. The solution you have outlined will A: Not work for all scenarios B: Will muddy the model if I have an agg-root structure 5 classes deep because each needs a reference to the root. I maintain that only the app layer knows the context in order to determine what the validation root is.

Roger commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Fri, 12 Jun 2009 07:57:58 GMT

That's pretty much the way we've solved it in our project - with one difference. The part you skipped, no duplicated lockmode.force for the same root, we found it hard solving nicely with event listeners because of their stateless nature. Quite doable but it became quite messy for us when we went that path (most probably because of lack of knowledge about listeners from ourside). We used an iinterceptor instead where we found it it easier to keep data "per session" (or here rather - per tran).

Michael Hart commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 23:06:56 GMT

What about value objects? I have plenty of value objects in my aggregates, but there's no way I'm introducing a reference back to the aggregate in them.

Bryan commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 22:34:30 GMT

@Stephen In a very large system you would probably make Comment it's own aggregate root independent of Post. The additional complexity of having to query for Comments separately from Posts is a trade off against scalability of the system. In a simpler system, you might have Post be an aggregate root that contains all Comments. It's easier to reason about what is happening inside the database, you'll write less code, but scaling will be more difficult. It all depends on what you are a building. Are you building Slashdot, or are you building your own person blog?

dkl commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 21:37:40 GMT

I guess it would be easy to support not only members referenced directly from aggregate root, but the whole subtree, including intermediaries. You just have to implement both ICanFindMyAggregateRoot and IAggregateRoot on the object and add some while cycles to ForceRootAggregateUpdateListener methods, right? (It would make sense to use three interfaces in this case, like IAggregateRoot, IAggregateChild, IAggregateIntermediary)

Stephen commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 21:23:08 GMT

In your example, is this really a place where you would care about locking the aggregate.. Perhaps I've not built large enough systems, or just ignorant with domain driven design.. but, the intent is to add a comment to a specific post.. why would you care that its changed since you loaded it? In this scenario wouldn't this simply cause many 'add comment' actions to be rejected on what would be an extremely busy blog.. whilst really serving no purpose.. I can understand it for other things like.. your scenario where a person has multiple phones and the contact had changed since you loaded it.

Ayende Rahien commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 20:27:42 GMT

Lucio, For demos, forsure. Anything else, not realy.

Lucio Assis commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 19:47:55 GMT

Do you really write the below repeatedly all throughout your code? using (var s = sf.OpenSession()) using (var tx = s.BeginTransaction())

pete w commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 17:53:07 GMT

Very slick. Works provided youve got a single aggregate root and not many, but maybe thats just me being a "DDD-ignoramus".

João P. Bragança commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 17:00:31 GMT

private static void ProtectMyDomainModelFromDomainDrivenDesignIgnorance... I would have spit coffee all over my monitor had I been drinking coffee at the time!

Bryan commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 16:51:35 GMT

Very interesting... I have to stew on this a bit, but we were essentially moving down the path of trying to solve the same problem. We were doing it by having the repository refuse to save an aggregate unless you explicitly locked it and keeping track of which aggregates were locked internally. Then, we built dirty tracking into our model. Our strategy works, but it still requires too much code in the model to track the changes and you have to manually acquire the lock which is yet more code to maintain.

Ayende Rahien commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 16:19:07 GMT

Frans, It is not hard coded value, it is a parameter that is set to version+1

Ayende Rahien commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 16:17:09 GMT

Yes, it is, removed

Frans Bouma commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 15:03:52 GMT

If another thread has already updated Post, the version is different, so the update fails. However, semantically one could argue that it should have been version+1, instead of a harcoded value.

Remco Ros commented on NHibernate – Automatic change tracking for aggregate roots in DDD scenarios

Thu, 11 Jun 2009 14:50:10 GMT

var words = File.ReadAllLines("words.txt"); so... is that a left-over from your previous post? :-)