in Search

Do you Twitter? Follow us @CodeBetter

Dave Laribee

"Whoso would be a man must be a nonconformist." - Ralph Waldo Emerson

More General Thing Madness

This description of problem analysis by Reginald Braithwaite (who is a smart person) struck a chord with me:

I found this to be an important point in my own programming, and I don't know if that's a general point but quite often we see something and we are very tempted to say "Oh, this is a special case of a more general thing", and then we solve the general thing. However that is an infinite recursion, it's always the special case of something more general. And if you are always climbing up the tree into the more general thing you will eventually wind up with a PhD in computer science and no code.

I know one of the areas that I get into trouble sometimes is when I try to make something too meta, too flexible. One of the things we abandoned early on at Xclaim was a very flexible party/roles management system that was so general -- it would have modeled anything -- but it was nigh impossible to represent in as a consistent and meaningful user experience and programming interface (developer experience). I try to stay more mindful, as an applications guy, of my abstractions now and root them in the concrete problem.

For me, learning and flexing DDD was a really useful approach for all sorts of domains and reigning in my tendency to get too abstract. As a method, you can apply it (in part, at least) to really any domain: vertical or horizontal. Patterns such as bounded contexts, intention revealing interfaces, the core pattern language, and ubiquitous language can keep you from falling into the pit of meta-meta-meta-madness.

Published Sep 22 2008, 08:24 PM by Dave Laribee

Filed under: analysis, DDD, opinion

Comments

Ian Cooper said:

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

# September 23, 2008 4:22 AM

Ollie Riches said:

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.

# September 23, 2008 2:37 PM

Dan Bernier said:

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.

# September 24, 2008 6:28 PM

Colin Jack said:

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?

# December 9, 2008 10:49 AM

Colin Jack said:

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

# December 9, 2008 10:58 AM

Dave Laribee said:

@colin_jack - That's exactly what I mean. When you have classes like "party" or "role" in your system that doesn't really tell you much. These are not part of the UL (usually) and reflect a developer's tendency to over abstract a solution.

# December 9, 2008 1:36 PM

Colin Jack said:

@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?

# December 9, 2008 2:16 PM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?