Documentation

Design principles

To really understand Domain-driven design, you'll also need to understand the design principles that are fundamental to implementing DDD and writing maintainable code in general. On this page I've attempted a summary of what I think the most important principles are.

If you want to read about them in dept there are plenty of articles on the internet. You could start with the enterprise craftsmanship blog or with this list on github for example.

The single responsibility principle

Each class or function should do one thing, and do it well. Or differently put, it should have only one reason to change. If you start using words like and, it's time to split up your classes or functions.

High cohesion and low coupling

Having a high cohesion means that stuff that belongs together, is grouped together. Low coupling means things are mostly independend from one another. This holds at all levels of your code. From applications talking to one another to the functions in a class.

Fail fast

If something goes wrong, just stop and throw an exception. If something breaks, or an assumption doesn't hold anymore, make sure you will notice it quickly instead of allowing it to corrupt your data or internal state.

Principle of least astonishment

Other people (and future you) will read your code. Make sure they'll have a good idea what it does without having to read every detail.

YAGNI and KISS

These stand for You Ain't Gonna Need It and Keep It Simple, Stupid. The idea is to not waste time, energy and readability by implementing things or abstracting things away because 'in the future we may need it'. If you don't need it now, don't do it. The future often tends to work out differently and even if it doesn't, we can just change it then.