the ‘bee log

If you can’t tell I’m catching up on Udi’s blog. He’s got a post up with some commentary about Martin Fowler’s “Anemic Domain Model Anti-Pattern” and it’s typically insightful so read it.

If Domain-Driven Design taught me anything it’s that Domain Model isn’t a pattern in itself; it is a Pattern Language. This is an “aha moment” I first had at my DDD talk at the CodeCamp NYC. It actually occured to me while I was giving the talk and it’s just now resurfacing again in my consciousness. So, as I like to proactively avoid those Howard Hughs moments, I’ll get it all out now.

A Pattern Language is a network of related patterns that apply to a single vertical or horizontal domain of variable size. They’re described as networks because patterns bare association and compliment other patterns in the same language. This can be seen in DDD, for example, in the connection between Entities, Factories, and Repositories. A pattern language usually .

Of course, domain model is be well expressed with the patterns in the Evans book but it works quite well in conjunction with the classic, GoF design patterns, etc. In this sense I’d say that DDD is a subset pattern language of the larger Domain Model pattern.

Domain Model also encompases patterns beyond what we think of as “software design patterns,” those little static structure diagrams and problem/context/forces/1000-words-or-less (generally) descriptions. Choosing Domain Model and doing it effectively means adopting a variety of principles or, what I like to call, Work Patterns. These are the kinds of important principles often talked about such as OCP, SRP, Demeter, Polymorphism, Encapsulation etc.

The Domain Model Pattern Language doesn’t stop at knowledge of principles or best practice it can go into larger methods such as TDD, BDD, Mocking, and Refactoring. More often than not these Work Patterns are habits that come from practice and manifest themselves in your code as “doing the right thing” and making “good choices.”

If this post had a point, it’s only to share the idea that Domain Model is a big, big thing. It’s probably overkill in a lot of cases where you have simple applications that have very simple purposes. If you’ve got a complex application/domain — especially one that’s going to live a long time (and don’t they all) – it’s a great choice. You gotta build these things from scratch, friends, and there’s no ActiveRecord/SubSonic safety net that’s going to do it for you. You should, however, know that when you choose Domain Model and plan on getting it right, you’re committing to a rich and integrated lifestyle.