Thread by @al94781

In my life as a consultant I've seen many peeps adopting Domain Driven Design.

Things go wrong a lot; and frequently the problems start in the initial stages.

So I made a thread to share my thoughts and tips on the subject of starting out.

(Please comment. I love feedback.)

When I say "Domain Driven Design" I'm talking about the design process introduced by Eric Evans (@ericevans0) in his 2003 book "Domain-Driven Design: Tackling Complexity in the Heart of Software". amazon.com/Domain-Driven-…

This book, while incredibly readable (one of my top three books for devs) also puts people off with its heft. (Understandable.) There are related works too (Implementing Domain Driven Design by Vaughn Vernon (@VaughnVernon) being the most well known.) amazon.com/Implementing-D…

Consequently, there are distillations (Vaughn himself has one: "Domain-Driven Design Distilled") but there are others. The one I like best is "The Anatomy of Domain Driven Design" by Scott Millet and Sam Knight leanpub.com/theanatomyofdo…

Yet peeps are still getting put off by the sheer volume of info, and perhaps even the options for how to start.

That makes me sad, because DDD is _the_ thing which keeps me sane on projects, keeps code bases in line and close to the business problem, and most importantly helps teams organise and *deliver*.

So what's step one?

Step one is to forget about DDD.

Completely.

Remember the days _before_ you knew about DDD and you'd just model your software domain using boxes and lines?

Do that. Have fun. Simply try and understand what problem you're solving with your software.

Forget Bounded Contexts, Ubiquitous Language, and all that other DDD stuff. Even forget the word "Domain".

Go on.

Let go...

Now lets try and understand our _business_ problem.

As you do this it's nice to be thinking using the same concepts you'll use to write code - that is to say, if you're going to write code in an Object-Oriented language, model in an OO way too. [See Note-1 in a few tweets.]

Ideally you'll have a whiteboard, but online tools like draw.io are great too.

Don't worry, you don't need to be a UML-master.

Take a look at Simon Brown's (@simonbrown) stuff for easy ways into this if you need it.

And the old but great "UML Distilled" by @martinfowler is also very handy.

[Note-1] E-R modeling isn't a great way to model for DDD. Instead, pick something which lets you focus on _behaviour_ and the data *together*.

You'll also probably need rich concepts like composition and interfaces as first-class citizens.

As you do this, remember to keep moving to the code - keep the loop between a sketch on a whiteboard and the corresponding code _super_ tight.

Remember - peeps who write the code should draw sketch-diagrams, but peeps who draw sketch-diagrams *must* write code.

As you go, treat yourself to a separate place in your code-base to keep things which are model-y. I like to make a package called "model" but others call it "domain".

Either is fine. Make yourself and your colleagues happy.

Add sub-packages if you like.

As you proceed with this you are allowed to start getting a little frustrated when stuff creeps into this "model" package which isn't really model and is more like framework / plumbing stuff.

This model-pollution _always_ happens - when I started it was coming from EJB bits, and these days it's just as likely to be Spring stuff.

Live with this pollution of your model for a little bit. It's fine. Just get used to the feeling of it frustrating you. It's a good feeling to recognise.

As you model make sure you keep in close contact with the experts who really understand the real-world version of the system you are building. Perhaps they will be the eventual users.

Treat them as your co-developers. They know the problem in super-detail, but don't know how to code (probably). You are the opposite.

Join forces with them to _really_ get your head round the difficult bits and build awesome solutions!

Keep things easy for your experts by using the words they use to describe their world in the software. Not just the nouns, but the adjectives too.

Listen _really_ carefully to your expert's words. All of them.

Ask lots of questions to get clarity and shared understanding, but never impose your words on them.

Help drive this shared language and model by writing the unit tests in language that the experts are 100% comfortable with.

Aside: TDD and DDD _love_ each other. They are _more_ than compatible, they are mutual force-multipliers.

Use your collaborators as an expert-lens to identify technical plumbing / framework things that have crept into your lovely clean model.

Move all these things out of your "model" package to somewhere else in your code base as soon as it is comfortable to do so.

Check you've been successful in this clean-up by showing your code to one or more of the expert colleagues.

If it makes sense to them (with a little explanation about the syntax of the language you are using) you're on the right track.

Pro Tip: Keep things legible.

If you get to the point where your model and the experts disagree, they are right and the model is wrong.

Change your model. This is a breakthrough!

(Congratulate yourself on earning your first DDD Merit Badge.)

If you never hit any problems after this then congratulations! You're doing Domain-Driven Design!

Treat yourself and have a first look at the Blue Book.

Read up on:

* Hands-On Modellers
* Ubiquitous Language
* Repository Pattern

amazon.com/Domain-Driven-…

You may however get to the point where your model as-is can’t solve the problems you need it to solve _all at once_.

This is 100% fine. That just means there is probably no way to do this with a single model.

Quick check - are all the elements in your model present because they are needed to solve the problem at hand?

If not, remove them. All models are _abstractions_ of the real world and don't need to contain everything it does.

Fix it by splitting the code in your "model" package in two. Re-distribute your code accordingly.

Pro Tip: You'll probably want to go back to the whiteboard for this.

But some bits of my original model are now needed in two places!

(Grrr! Frustrating!)

That's _totally_ fine. Simply go ahead and duplicate the bits you need. [See Note-2 below]

Pro Tip: Make sure you _only_ copy the bits you need. (I.e. fields/attributes and methods/functions.)

Keep both your models lean, mean and problem-solving focused.

[Note-2] Worried about not being DRY? Read this by @mathiasverraes: verraes.net/2014/08/dry-is…

OK, now I have two models solving two problems, how do I know what code goes where?

The answer is "speak to your experts" again. They will likely have been thinking about two jobs when they explained things to you.

Pro Tip: Get them to think about job titles and "hats" they might wear at different times of their working day.

Make sure your model splits along those lines.

As they explain things going forward ask them "which hat do you have on when you're doing this?"

Congratulations! You've now discovered your first _pair_ of models.

What is more, you've discovered the need for Bounded Contexts too.

Give yourself another DDD merit badge!

Treat yourself again and have another look at the Blue Book and read up on Bounded Contexts

amazon.com/Domain-Driven-…