Getting Started with DDD

What is DDD?

DDD is Domain Driven Design. It is a design paradigm that focuses on the language used in software and it’s alignment with the business domain. It uses binding context’s to create business-centric models which solve problems as they are modelled, described and discussed by the business/industry.

Why Do I Care?

Software is about translation – we developers take the business problems and translate it into a solution (provided by code). We not only have the problem of finding a solution (often with tight constraints) but also having to translate all the business lingo into geekspeak. But why? Why do we need to translate? Modern development languages have very rich support for integrating your own language into the code. Why do we add a problem that no longer needs to exist? We should focus our core efforts on finding the solution and not the translation in the middle.

Perhaps oddly enough – a great way to do this is by focusing on integrating the language into the solution from the outset. There should be no translation, the software is the translation. This “integrated” language is the common language, the ubiquitous language.

What Will DDD NOT Do?

• Dictate/define a new testing format/practice (you do have a testing practice, right?). TDD’ers can work fine, although BDD’ers naturally have a better fit since they are already a step towards using the ubiquitous language in their behaviour definitions.
• Change the way you work overnight. The DDD concept is relatively simple. But implementing is hard, we need to change the way we work. Namely, us geeks need to get our social skills sorted, talk to the business and perhaps more importantly - truly understand the business. This may mean dropping the horrible “I’m more intehwigent than you” complex that (sadly) many geeks seem to have. Be bold. Don’t be afraid to say “I don’t know” and ask for clarification. The business will thank you when they actually have working, useful software. A good BA can help here in facilitating these talks.
• Give you the solution. DDD is no silver bullet and goes no way to actually helping you solve the solution (we have to get paid to do something right?). However, DDD will get you so much closer to the problem that it will make it easier to solve in the most elegant way possible.
• Get it right, first time. Due to the fact that us geeks spend a lot of time studying/learning to stay just on top of the software industry, we unfortunately have little knowledge of other business domains. This means we need to learn a lot. And we will get it wrong. Our first few designs will be totally out of whack with what the business is actually trying to communicate. That’s fine. Do it again. DDD will force you to rethink and work on your prototyping skills. Rapid prototyping and spike solutions will become a much larger part of your arsenal because we are going to get it wrong. Get it wrong while it’s cheap!
• Prevent good technical design. Some geeks have aired concerns that all these classes with “jumped-up business terms” are polluting their awesome, technically perfect and soundly-engineered code. Well, I am a straight-shooter, so: Grow up. If your design skills are that good you should have no problem isolating the (internal) technical design requirements from the language used. For example, there is nothing to stop a “TPSReportData” inheriting from the “XmlDataSource<T>”. The point is, when we have code being called in our domain model, we are talking about TPS Reports, not XML.

What WILL DDD Do?

• Get you much closer to the business. Both the people and the problem. This is rewarding on two levels: firstly, it’s great working with people - building relationships, trust and knowing you are genuinely helping them out. Secondly, being closer to the problem means you are more likely to find what people actually want and need. There are many times when you actually get to the crux of the problem (after several iterations) and discover it can be solved VERY easily. As opposed to the up-front (complex) design originally envisioned.
• Make you more employable. Increasing domain knowledge will also have the side effect of you developing some great industry knowledge making you more employable within that sector (ask any DDD’er that has worked a lot in the finance or medical industry).
• Make you VERY aware of the language used in code and tests. The language becomes critical to everything. I have found a real plus of this being that I have ditched a lot of confusing code. If I can’t articulate tests/code in the business language (when working on the domain model) then I question why? Often, it is because I have either misunderstood something, or I am trying to make the “thing” do too much and this responsibility lies in the “other thing”.
• Make you focus on the model rather than worrying about technical nuances/design. Now I know some of you are probably jumping around saying “the technical design is important!” – yes, I agree. But put simply, it is not as important as the domain model. Why? Because the biggest (but often neglected) constraint on the technical design IS the domain model! Get the model right first, then you can produce the cleanest, technical design to implement that model.
• Cause you to create classes with similar/identical names for different contexts. I thought I would mention this one in particular since it is one that people often have problems with. Let’s say we have a “Customer” object. We are modelling the base customer details which includes name, telephone number etc. All good. We then head over to focus on the billing section of the application. Oh, Customers need a payment method (e.g. credit card) so on goes the “PaymentMethods” property to the Customer object we created earlier right? WRONG. We have two different domain concerns here and they should be isolated from one another. Most modern development languages support namespacing, which is a nice solution to this problem. A “User.Customer” is not the same as a “Billing.Customer”, treat them as such.
• Require loosely-coupled “modules” which seem to add work. Think of modules as the “areas of concern” (e.g. the user of the application above is not the same area of concerns as billing). These modules need to be in isolation and loosely-coupled from other modules (e.g. we don’t use a “User.Customer” in the billing department. People can view the creation of these classes as overhead. Much like other principles/practices (such as automated testing) this cost is far outweighed by the benefit. The time spent on ensuring your model is right will pay huge dividends when that old chestnut CHANGE rears it’s ugly head. Changes are likely to be to a single “module” which is isolated so doesn’t cause ripple effects. Good practices are all-too-often dismissed for time-wasting. I say to these people this:

“Next time you go for surgery at the hospital, tell the surgeon to not worry about scrubbing up since most people don’t get infections during surgery.”

Would you? Of course not! Why? Because we know that if surgeons didn’t follow good practice then more problems would occur. Why is software any different? Yes we are still a relatively young industry (compared to medicine and other forms of engineering) but it doesn’t mean we can’t TRY to instil good practices now.

Getting Started

Like I said, you can’t “go DDD” overnight. But you can start right now. Grab a pen and paper, map your current software architecture with namespaces and sample class names. Think about how data is stored/retrieved – do you have monolithic “Customer” objects? Are there tables/objects that have data that is actually something else? Do you have geekspeak bubbling up into your domain layer? Do you even have a domain layer? (I am not kidding, I have seen many solutions with a “domain” class that has nothing to do with the domain model).

Now on a different piece of paper, map the business units, the terms they use and how they interoperate with each other. Now compare the two drawings, different much? Mine were! Now think about how you could develop the codebase into something more like the business model. Then do it. Rinse and repeat.

Focus on what the business wants and needs. Ditch the rest. This process is much easier when you are all talking the same language.

Links/Resources

• “Domain Driven Design” by Eric Evans. The “big blue book” – THE book for DDD. I personally found this a hard read since I don’t cope well with narrative books. However, solid knowledge and very informative.
• Domain Driven Design on Wikipedia.
• DDD Community Site
• “An Introduction to DDD” by David Laribee on MSDN
• “ThinkDDD” by @JakCharlton
• Rob Conery and James Avery discuss DDD on the ALT.NET Podcast
• Eric Evans DDD Talk at SkillsMatter.

To Close…

DDD is still very new to me, I have yet to do a project with it in the workplace, but some changes (for both me and the workplace) are required before I can do this (me first, lead by example). However, the concept is simple, and solid. I feel the same way about DDD as I did when I first started getting into TDD. It felt right. Almost like I have woken up some long-forgotten natural geek instinct.

I am now focusing a lot more on prototyping and understanding my domain. I will be honest, I am finding it hard – there are a lot of new terms to digest and understand (not just smiling and nodding). However, the more questions I ask, the more I learn and the more I am simplifying the model in my mind – which I can then apply in code. To be honest, I find it energising since it is enabling me to focus on what is REALLY required. And we all know how much of a fan I am for getting things done.. :)

Onwards and upwards!