Nice job on the article. I think the difficulty of explaining the concepts of DDD which your article reflects a bit, is most of the descriptions of the 4 w's in regards to DDD are so high-level and abstract it doesn't give the new developer much tangible to go on. This is one of those concepts where a full blown case study and implementation example (book, peer experience, etc) is one of the only good ways to understand DDD.

Ironic where that the term UL is introduced!

I had to read it 3 times to work out what UL was.

This sounds like fresh jargon for RAD as performed by a talented analyst / programmer.

Back when I was doing this kind of work in the mid to late 90s, the idea was to put together a demo prototype using MS Access or even Excel (I worked with accountants) and as they approved various sections of the tool, quietly migrate that section to a more supportable technology.

When this trick is performed correctly they never notice that the non-scalable Access database is actually drawing its data from an Oracle or MS SQL server.  They fail to see that when they click on the short cut to start the tool it doesn't start Access any more, it starts a properly written multi-user application using a more maintainable technology.

However the two things that must always be defined at the beginning are: The minimum functionality that will be acceptable at the completion of the job.

And the time allowed (even if only a rough guesstamate).

Without these the project becomes unmanageable.

Projects tend to be compared against what's in the customers head at the end rather than what has been negotiated along the way.   This must be documented and managed.  If the project is to automate a documented procedure, then the final project can be compared to that procedure document.  However if it is to support a new partially documented procedure, good luck!

I've completed projects in both these situations.  My main lesson was to always have the business reps get their procedures sorted out first and then get involved.  If the procedure changes a little along the way, then we can deal with that in version 2.0.  But if the changes are big enough to need to be incorporated up front, the procedure is not mature enough to be automated and there are better business benefits to be gained from utilising my skills automating other procedures.  The best you can hope for is that by working through thier procedure with your prototype they can find gaps in their procedure before they cause major problems.  However, the new procedure then has to be tested and allowed to mature in the non-automated world to make sure it still holds water before attempting to progress the project any further.

If the requirements list / procedure changes so often it can't wait for version 2.0 and the business is determined to forge ahead regardless, it should be trimmed to only include the sections of the procedure that aren't changing.  Let that be your version 1.0.  This gives the customer something solid to improve their productivity while they sort out the rest of the procedure, provides a deliverable to justify your pay and buys time while more of the new procedure is locked down.

One thing I definitely agree with is the need for a shared language.  The difference between myself and the other guy that was shortlisted for the position I mentioned above, is I had started some basic accounting courses before I applied and the other guy hadn't.

These days I work in the electricity industry, so I completed an AD Eng (Electrical and Electronic).  If I worked in the banking industry I would have completed a mid-level accounting / finance qualification.

Step 1: Understand your customer, thier business and their language.

Step 2: Understand what they are trying to achieve.

Step 3: Show them how you can help them to achieve that.

Step 4: Make it maintainable and scalable.

Your mileage may vary.

I see a problem with the second essential ingredient, the Domain Expert. They do need to be available all the time. If not the requirements will not be a living document, they will not be kept up to date.

If the Domain Expert is a member of the business, they will have other duties and not be available enough. If not they will not really have the expertise required unless they are a crack Business Analyst. If you have a crack BA then you don't need DDD.

In this case adding another language to bridge between business language and technical language opens the risk of everyone being misinformed rather than one party or another. A good BA will do this bridging without needing an additional made up language and syntax.

A case study would indeed be interesting.

Great article! Thanks for sharing, really helps a lot.

>This sounds like fresh jargon for RAD as performed by a talented analyst / programmer.

Russell, DDD is RAD in exactly the same way that Agile is RAD.  I.e. they share one or two traits, but that's it.

Like RAD, DDD involves close working with the domain experts - but unlike traditional RAD, it does so in a sustainable, manageable manner whilst ensuring a high level of engineering quality.

RAD, on the other hand, is generally very cheap and very very fast.  If you're on a tight budget and have a short deadline, then RAD is extremely effective.

I've worked with RAD, Agile and DDD methologies, and I must say that DDD is a fantastic as long as you get the buy in from management.  I.e. the second someone puts a wall between users and developers, it will go very wrong very fast.

Fantastic article. Well elaborated and also to the point.

So, the Domain expert, is not really the project champion, he is an expert in the line of business who knows the intricacies involved within the business domain, it's chanllenges and what is expected of the technical or development team to cater and solve business requirements.