Domain-Driven Design — Practical to Tactical

..and dare I say, Strategic?

 On the Domain-Driven Design group (http://tech.groups.yahoo.com/group/domaindrivendesign/), Bil Simser lays out a common question:

“It’s all great to talk about repositories and aggregates and context boundaries, oh my, but the real challenge is making that connection from theory to practice. Then taking it even further (because presentation style and book samples can only go so far) how to you apply it to real-world apps?”

A fair question, and one that in recent weeks has been much on my mind (apologies to the late Graham Chapman).

The key to transitioning from book knowledge to practice, is perseverance.   Perseverance and cover, if you work in a big IT/development organization.  It’s absolutely required to have executive sponsorship in order to move the organization in any particular way.  It’s especially important to allow you to move towards any methodology that hints of ‘Agile’ as DDD does.

My approach (to move developers) has been to recommend “The Pragmatic Programmer: From Journeyman to Master” (ISBN: 020161622X).  This one book changed my programming life.  It led to my joining ThoughtWorks and it led to my current position trying to bring agile sensibilities to a large, developmentally conservative department in Southern California.  There are several other technique books that are well written and great for developers.

As for the management (development and business), it really requires patient conversation and the gentle application of the five ‘whys’.   There are also some great books available in this snack bracket.  Craig Larman’s “Agile and Iterative Development: A Manager’s Guide (ISBN-10: 0131111558) is a good one, but there are others. 

Eventually, if it’s possible, the management will hear what you are saying and sponsor a trial.  You need to select your team carefully.  As I’ve written before, occasionally there will be saboteurs assigned (wittingly or unwittingly).  You really need to be disciplined, and perform the project ‘by-the-numbers’.

One key strategy I’ve found is to get to the users directly.  You can start having conversations with them along the lines of “What bothers you about your job, day to day?” or “What one feature would make your work life easier?”  These conversations break the ice, and if you’re doing it carefully, they will start talking to their management about things they like/hate about the applications they use.

I don’t use subterfuge though.  I say what I’m after and why.  I’ve found that the most important thing that management should consider is business value delivered, and because of that, I’m interested in the business reasons for the users’ actions.  Very often, they are performing functions that have nothing to do with delivering value to the business.  They are forced to do some arcane tasks to support an inflexible legacy application, or surprisingly, because no one asked what they were really trying to do, and why.  Developers (usually under the gun to do something quickly) simply made assumptions about the technical way to accomplish what the user asked for, probably filtered through one or more intermediaries. 

Ever heard of the childrens’ game “Telephone”?  It’s not a surprise that users don’t get what they want most of the time; but I digress.

Once you have access to the users, get as much of their time as you can.  Ask all the questions that can help you start to build that “Ubiquitous Language”.  Iterate over the language and the concepts with a tight feedback loop, and you’re on your way.

If you’re having trouble getting to this stage, perhaps you need an agile coach to help educate the apprpriate people.  I know a few really good ones.  Drop a line if you need a referral.

Seriously.

Advertisements

3 thoughts on “Domain-Driven Design — Practical to Tactical

  1. I know it’s difficult to get to the users sometimes, especially if you feel bound to get to all the users 😉
    The trick (obviously) is to identify the high value users; the ones that have the insights into their use of the (proposed) system. If you find one of them, they’re worth a dozen of the rest.
    Insist on getting the word from the horse’s mouth! Intermediaries almost never have the appreciation for the tasks being performed and often have opinions that will led you astray.

  2. I find it interesting to ask the users:

    1. Name your 3 biggest pain points.
    2. Name the 3 things that take up most of your time.

    I’m always amazed at how the two lists rarely coincide and how often the pain points consume an insignificant amount of time. Asking the users what can be improved is sometimes a dangerous path leading to software features of questionable value. Users often list the portions of the job that they find distasteful, not necessarily the portion of their job that may render the greatest value to the company through automation. Sometimes user observation is a surer method of revealing valuable candidate features.

    But to your point, it is paramount to have close interaction with your users, to gather their input, observe their processes, and judge their objective capabilities to help steer the software.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s