Domain-Driven Design and OOP: friction = traction

Spread the love

A few days ago I read a really great post by Seth Godwin about Traction and Friction. He’s not a programmer (as far as I know), but writes a lot of insightful articles about strategy and value that can be applied to everyday subjects.

This particular article struck a chord in me as a good metaphor for the benefits domain-driven design brings to object-oriented code. Here’s a snippet:

A big car on a wet frozen lake goes nowhere. No traction, no motion.

A small bug working its way across a gravel driveway takes forever. Too much friction, too little motion.

If you’re stuck, it’s probably because one of these two challenges.

The power of online platforms is that they create traction. No, you can’t write more than 140 characters, no you can’t design any layout you want, no you can’t spam everyone with your inane sales pitch. You have something to leverage against, but it’s that thing, the friction, that makes it work.

Object-oriented languages like C# or Java are very powerful things. They provide an infinite canvas on which you can create just about anything, including a huge mess — like the car on the frozen lake — if you start coding without any rules to guide you.

DDD on the other hand provides principles and patterns you can leverage and push off with, like the side of a swimming pool. No you can’t put UI logic in the domain layer, no you can’t use a dataset to model an important business concept, no you can’t reference this entity without going through its aggregate root first. This friction is what makes DDD effective — it gives traction to your OO code.