"... the key to expert performance in many fields
is domain knowledge rather than intelligence." Don Reinertsen

Domain Driven Design
is a software development methodology, intended to achieve a software system
closely modelled on and aligned with real business processes.

Traditionally
development tends to be a technically led process, where requirements are
passed from the business to the development teams, and then the development
teams go off and produce their best guesstimate at what the requirements said.

In a waterfall
approach this leads to large requirements documents that are diligently
collated, analysed, reviewed and approved. These documents are then given to
development teams to turn into working software.

Agile approaches can
also accept the requirements documents that waterfall tends to produce, but for
them to actually progress forwards they must be broken to small tasks and
stories which can then be queued ready for development.

Domain Driven Design
to a large degree steps back from these two distinct ends of the spectrum, and
looks at how the requirements are gathered in the first place - if you like, it
bridges the gap between doing everything up front and everything at the last
minute.

DDD understands that
requirements are never 'done', but exist as a living document. More
importantly, the living document in question is actually the software itself -
all other documents are an artefact and reflection of the code.

As the software
system develops and grows, deeper understanding of the problem grows too - DDD
is all about the discovery of the solution through deeper understanding of the
problem.

Where DDD really
differs though is that it sees the software system as a reflection of the
business process, an enabler rather than the driver. DDD is deeply concerned
about the business processes, business terminology and practices. Technical
concerns are largely secondary and a means to an end.

The Ubiquitous Language is at the centre of DDD - this is a shared and growing language. A
negotiated language derived from the business terminology and enriched by the development teams. If a business person doesn't understand a term in the UL,
then the chances are the UL needs an evolution. If a technical person doesn't
understand a term in the UL then the chances are they need a conversation with
a Domain Expert.

The Domain Experts
are the second essential component of DDD - people who deeply understand the
business domain, and the business itself. These people are integral to the
development process. They may not be required "full time" like the
traditional Product Owners of some Agile methodologies, but they must be
accessible continually, and be prepared to invest time in the process. Domain
Experts are not to be considered outsiders, but as the core of the DDD process
- they are as much a part of the development team as any developer or tester.

DDD doesn't begin
and end - it is a constant process of re-evaluation, refactoring, remodelling
and redesign - every conversation should bring you to a closer understanding of
the problem. At no point is DDD 'done' - it is always there; the Ubiquitous Language
grows and develops, the Domain Models change as understanding changes, code is
restructured and refactored to better represent that understanding.

Artefacts will come
and go, but only one really matters - the code base. It is the only expression
of the solution that is free of abstraction. While documents may try to explain
or describe the system, only the code does so without losing information. This
means that in DDD the code must remain of high quality, be clear and
expressive, be free of technical abbreviations or jargon, and as far as
possible should make at least some sense to a Domain Expert when explained to
them.

Clever code doesn't
work in DDD, nor do magical processes or "you don't need to know"
components. Domain Experts shouldn't need to become developers to understand
what the key parts of the software system is doing for them.They also shouldn't need to think in terms of
databases or batch jobs or other technical concerns.

DDD is the ultimate
expression of Agile - it is about dealing with a constantly shifting and
evolving set of requirements - because as anyone who has ever been involved
with a software project knows - it is very rare for a requirement to remain
intact from the beginning to the end of a project, and almost impossible for it
to do so as the business grows and changes.

Through constant
conversations, DDD will guide you to an ever more accurate software
representation of your business process.

Comments

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.

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.

David
wrote
re: What is Domain Driven Design?

on 05-18-2011 1:44 AM

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.

Carl
wrote
re: What is Domain Driven Design?

on 05-18-2011 1:48 AM

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

Ryan
wrote
re: What is Domain Driven Design?

on 05-18-2011 4:01 AM

>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.

Technology
wrote
re: What is Domain Driven Design?

on 05-20-2011 4:15 AM

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.