Collection Encapsulation and Business Logic

Yesterday Colin Jack and Jimmy Bogard had a fantastic exchange on Twitter about dealing with collections in your Domain model, and Derick Bailey also blogged about his thoughts on the matter. While I didn't take part in the conversation, I did have a conversation with him at ALT.NET UK about his solution and blog post.

The Twitter conversation lead to a discussion about both proposed solutions with a friend of mine that is starting a Greenfield project and I thought I would join the bigger conversation too. I'm not going to show any code, as Colin and Derick already have great examples.

Custom Collections

Colin's solution involves using custom collection collections. This gives him the flexibility of implementing the interfaces he wants to deliver the functionality he requires: read only, management of adding/removing items, etc.

Personally, I'm not keen on this solution. I've been down this path before a few years ago, and it did not end well. I felt that it lead to a dilution of business rules, split between the Aggregate Root and the custom collection and added needless complexity where a simpler solution would do the same job. I also ran into a few issues with introducing new team members, as most of them went the IList<T> route if left on their own.

Colin writes:

I've found that it just results in my aggregate roots and key entities getting bogged down in lots of boring collection work so I prefer to farm out this work to custom collections.

I don't really agree that the collection work is boring; for me, the collection work will generally lead to apply some form of business rules or satisfying bi-directional relationships.

IEnumerable<T>

This solution is presented in Derick's blog post and is my current preferred solution. We get the functionality we want, a read-only collection exposed on the Entity and we control the interaction with the collection within the Aggregate root and that's where I feel the interaction should be controlled. I also think it's the simplest possible solution to achieve what we are looking for without compromising the Domain. I also find it more discoverable and readable when seen in the context of the Aggregate root instead external in a custom collection.

So...

As Derick noted in his post, "Like everything else in software development, there are multiple ways to solve the same problem." and I completely agree. I've been in my current position for 3months and while the code base and Domain is small, it's already starting to get fairly complex. My work is a debt management and solutions company, and after working with e-commerce/warehousing solutions development and marketing agencies for the past 6 years, the domain is completely alien to me. Encapsulating all the core logic in the Aggregate root has been really beneficial for me so far as it's fairly easy to locate and work with whenever the requirement's change... or when I just get it plain wrong.

Returning to the conversation with my friend, I pushed my own solution at him but made it clear that Colin's solution is worth keeping in mind. As my companies Domain gets bigger and more complex, I wouldn't think twice about refactoring to Colin's solution if it would ease any headaches that manifest with my current solution.

Thursday, October 23, 2008 5:32 PM

Your Comments.

# re: Collection Encapsulation and Business Logic

> Personally, I'm not keen on this
> solution. I've been down this path
> before a few years ago, and it did not
> end well. I felt that it lead to a
> dilution of business rules, split
> between the Aggregate Root and the
> custom collection and added needless
> complexity where a simpler solution
> would do the same job.

I certainly don't think you want your aggregate roots to do all validation so I think splitting it out is definitely worth doing. Your aggregate roots co-ordinate the validation, but thats a very different undertaking.

Each entity/Value Object should manage its own rules and in my view the same goes for collections.

Plus collection validation is very different as I tend to do it upfront. For example if you set Customer.Address to null I might allow you to continue, you can find out whether this is allowed by calling customer.IsValidForX (if you don't I'll tell you at the appropriate time e.g. before persistence). However if a Customer has a collection of Accounts and if you try to add an Account that would invalidate the contents of the collection then I'll tell you there and then that it isn't possible. I do this as overall it simplifies validation (just as Value Objects simplify persistence).

> I also ran into a few issues with
> introducing new team members, as most
> of them went the IList route if
> left on their own.

Definitely, but then domain models are things that need understood and carefully managed. Theres really no away around that.

> I also find it more discoverable and
> readable when seen in the context of
> the Aggregate root instead external in > a custom collection.

First I should point out that *if* you want the methods on the aggregate root then you can still do that even with a custom collection.

However Evans quite rightly points out (pp93):

"Rather than focussing on the attributes or even the behavior strip the ENTITY object's definition down to the almost intrinsic characteristics....look to remove behavior and attributes into other objects associated with the core ENTITY."

So why do I recommend that? Well if your aggregate root, say Customer, has multiple collections (Addresses/ContactDetails/Accounts) and you put all the methods on that classes interface then you get a muddle especially if the methods are not grouped. You could use interfaces (IAddressHolder) but thats interface SRP not implementation SRP.

If you go a step further and avoid using custom collections all together then all the code for managing those collections is in the aggregate root too, its not just the loss of SRP thats the problem but also that the class quickly gets unmanagable.

Left by Colin Jack at 10/23/2008 7:02 PM

Your Reply.

Comment Form.

Fields denoted with a "*" are required.

*Your name:

*Subject:

You may also like to leave your email or website.

*Your message:

Please add 7 and 7 and type the answer here:

Enter the code shown above:

Preview Your Comment.

# re: Collection Encapsulation and Business Logic
> Personally, I'm not keen on this
> solution. I've been down this path
> before a few years ago, and it did not
> end well. I felt that it lead to a
> dilution of business rules, split
> between the Aggregate Root and the
> custom collection and added needless
> complexity where a simpler solution
> would do the same job.

I certainly don't think you want your aggregate roots to do all validation so I think splitting it out is definitely worth doing. Your aggregate roots co-ordinate the validation, but thats a very different undertaking.

Each entity/Value Object should manage its own rules and in my view the same goes for collections.

Plus collection validation is very different as I tend to do it upfront. For example if you set Customer.Address to null I might allow you to continue, you can find out whether this is allowed by calling customer.IsValidForX (if you don't I'll tell you at the appropriate time e.g. before persistence). However if a Customer has a collection of Accounts and if you try to add an Account that would invalidate the contents of the collection then I'll tell you there and then that it isn't possible. I do this as overall it simplifies validation (just as Value Objects simplify persistence).

> I also ran into a few issues with
> introducing new team members, as most
> of them went the IList route if
> left on their own.

Definitely, but then domain models are things that need understood and carefully managed. Theres really no away around that.

> I also find it more discoverable and
> readable when seen in the context of
> the Aggregate root instead external in > a custom collection.

First I should point out that *if* you want the methods on the aggregate root then you can still do that even with a custom collection.

However Evans quite rightly points out (pp93):

"Rather than focussing on the attributes or even the behavior strip the ENTITY object's definition down to the almost intrinsic characteristics....look to remove behavior and attributes into other objects associated with the core ENTITY."

So why do I recommend that? Well if your aggregate root, say Customer, has multiple collections (Addresses/ContactDetails/Accounts) and you put all the methods on that classes interface then you get a muddle especially if the methods are not grouped. You could use interfaces (IAddressHolder) but thats interface SRP not implementation SRP.

If you go a step further and avoid using custom collections all together then all the code for managing those collections is in the aggregate root too, its not just the loss of SRP thats the problem but also that the class quickly gets unmanagable.

Left by Colin Jack at 10/23/2008 7:02 PM

Jump Menu

So what are all these buttons for?

Personalize

Text Size

Layout

Navigation Position

Chris Canal

Scottish ALT.NET Developer

Collection Encapsulation and Business Logic

Custom Collections

IEnumerable<T>

So...

Your Comments.

Your Reply.

Preview Your Comment.

Archives

Post Categories

Blogroll

Social

Syndicate