Sadly I work somewhere where the more generic party roles model made into production for some of our systems. You made a good call.

I hear the pain of party\role management :)

What ever happened to that useful phrase 'anti-pattern' it seems to have dropped out of use.

Like the Flexibility-usability Tradeoff:  "As the flexibility if a system increases, it becomes less usable [Universal Principals of Design, p86].  Solution: make opinionated sites and apps for the right kind of people (don’t be everything to no-one)."  (from http://www.azmwd.com/)

It brings to mind a friend who always talks about "ultimate flexibility."

"...that is an infinite recursion..."  It's bits like that that kept Reg in my RSS reader for so many years.

I have to say I like the party-role pattern a lot, not always applicable but when you need it you know you need it.

Surely the trick is just to tie it down in your knowledge level, so perhaps when you go to a Customer role class it only has one method to CreateAdviceRelationship. In this case the model is flexible but using it is easy?

Just re-reading this bit:

"very flexible party/roles management system that was so general -- it would have modeled anything"

Do you mean manage any relationship between two parties (Person/Organization) where each has a specific role in the relationship (e.g. Employer)?

@Dave Laribee

Ta for replying and get you on terminology, there was a recent discussion on this in the DDD forum (see Ubiquity of Language).

I agree that Party and Role don't have domain meaning, but the subclasses of Role should have (Customer, Advisor etc). On the domain meaning side you can also hide the Party (c2.com/.../wiki) but I've not tried that approach.

Disagree that its necessarily about over-abstraction though, sometimes you need the abstraction. For example you have Customers who can be People or Organizations but not all People are Customers. Party/Role handles this nicely, other approaches don't tend to. So for me the abstraction should be coupled with concrete subclasses and helpful methods like "customer.CreateAdviceRelationship(advisor)".

Strangely I've tended to meet developers who under rather than over abstract, they just wouldn't think of splitting roles from parties.

Oh and fully agree its not a pattern to apply upfront though.

Thoughts?