What is Domain Driven Design?

 

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

 

 


Posted 05-16-2011 3:15 AM by Jak Charlton

[Advertisement]

Comments

Allen wrote re: What is Domain Driven Design?
on 05-17-2011 3:59 PM

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.

Lee wrote re: What is Domain Driven Design?
on 05-17-2011 4:58 PM

Ironic where that the term UL is introduced!

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

Jak Charlton wrote re: What is Domain Driven Design?
on 05-17-2011 7:09 PM

Lee - Have linked Ubiquitous Language in the article - hope that helps others

Russell wrote re: What is Domain Driven Design?
on 05-18-2011 12:08 AM

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.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)