A crucial threat against a project’s success is that it’s
being put off course by developers having too much attention on technical
issues, and hence forgetting to pay attention to the primary objective which is
to solve business a business problem. A key job qualification for a developer
is to know your programming language and the related technical frameworks, but
this is far from enough. To ensure success, you must strive to understand the
client’s business domain. You probably know a dozen technical design patterns,
but have you ever though about how similar patterns can be applied within the
business domain? Eric Evans, whom I’ve had the pleasure to meet on several occasions,
has written an excellent book on this topic entitled Domain
Driven Design. He also maintains a community website for people who are interested
in not just developing code, but also delivering business value.
I’m sitting at my workstation,
Got a two inch stack of documentation. (Mmm.)
And each page looks the same to me
With Visitors and Factories,
And every data class I see
Reminds me that I long to be...
Chorus:
Domain Driven
We wish we was
Domain Driven
Domain, where the code's not breaking
Domain, where my head's not aching
Domain, where the system's speaking
Constantly to me
Our craft is programming, and we can never have the same
knowledge about a business domain as a domain expert. Just as we do; domain
experts have their own lingo, so to be able to discuss the business domain with
the client you’ll need to get hip to the talk of the domain experts. As a
consultant I’ve worked with vastly different businesses, ranging from
transportation, to financial services and various governmental services to name
a few. Usually, clients don’t expect you to be a domain expert, but if you don’t
understand the business domain you run the risk of producing software that
doesn’t adhere to a client’s understanding of the business rules.
Every class an endless stream,
Of muddled names and responsibilities. (Mmm.)
The shallow model frightens me
With subtle bugs that I can’t see.
This software runs the company
Won’t domain experts talk to me?
(chorus)
In addition to being honest about only having layman’s knowledge
about most business domains, I have two sharp tools to swiftly gain knowledge
about arbitrary business domains; domain glossaries and Amazon. The Internet is
flooded with great glossaries of various terms used within different
industries. I’ve used glossaries of insurance,
agricultural, shipping and many
other terms. While glossaries are great to find the right name for an
entity or operation on a class, you need to dig deeper to gain knowledge about
the nuts and bolts of an industry. If you’re working on a project within the
insurance sector, Emmet
J. Vaughn’s Fundamentals of Risk and Insurance or even Jack
Hungelmann’s Insurance for Dummies might be a good place to start.
Tonight I'm staying late again,
I'll play the game and pretend. (Mmm.)
Our big design comes back to me
In shades of mediocrity,
Like emptiness in harmony
This architecture's killing me.
(chorus)
The lyrics are from Domain Driven – The song by Tracy Bialik
and Russ Rufer, and it should be sung to the tune of Paul Simon and Art
Garfunkel’s Homeward Bound. The song sings for it self, you should pay at least
as much attention to your domain design as you do to your technical
architecture. This doesn’t take the fun away from your projects, in fact it encourages
you to develop an agile, lightweight technical architecture that doesn’t get in
the way of the business challenges which is much more fun than writing a mega
framework for a minor problem just to learn that it just doesn’t work.