Domain-Driven Design has become quite a spread practice in the small bubble where I have interactions upon. For developers is like this desired way of doing things and for managers and HR people is just a marketing word, to feel that they have an advanced company for the former and to attract talent for the latter.

DDD is actually not that new, from the wikipedia:

The term was coined by Eric Evans in his book of the same title published in 2003.[4]

so it's been there for about 20 years, and if you happen to have gone to informatics/computer science faculty afterwards - I started right when this book was published - you probably studied many of the patterns and high level concepts this book explained. I encourage you to read the book, known as the blue book for its cover - you might experience like me a trip back to when you were studying "software engineering I" and "II".

It was 10 years later though that Vaughn Vernon came with his red book -also called like that because of its cover- to make DDD practice to really explode. This book is also a must-read. I must confess that I fought against slumberness while doing that, but it's OK to try to read it first, and then come back to it on specific doubts, because you'll remember that there was something written about that, like I did here.

I'd say he's been the one to push the usage of DDD with ports and adapters architecture (hexagonal architecture) and the next steps to Event Driven Architecture or CQRS+ES.

Now, the way I came across those practices was even later, the PHP world is high-jacked by all of those CMS (Wordpress, Drupal, etc) and that's what gives results fast - and the faster way to get a job after college - so it's been thanks to these guy: codely.com and this other guys: youtube.com/c/carlosbuenosvinoszamora to bring DDD to the PHP world, at least in Spain, and might I dare to say even to other Spanish-speaking countries. Carlos Buenosvinos co-authored book about DDD in PHP is also a must-read if you work with PHP. (I came across them thanks to my boss at the time, thanks for that!).

My experience then with DDD was that one of success, even though it was just the beginning, but knowing where was the appropriate place to write each piece of logic and how to find that easily, and start having less and less side effects from each function, it was giving results quite fast. But it took me many years of practice and especially reading the books that it all fall into place, and I could understand the whole narrative including even that of what I was taught at college.

Unfortunately, DDD is not as spread as it should be, and many early adopters have rookie mistakes when trying to apply them. Most of those mistakes are actually symptoms of the same problem: a miss-understanding or lack of the mindset. Hopefully, by pointing them out, I can help you adopt the proper mindset, but nothing will achieve that as nicely as you spending about 20 hours reading the books and some dollars (that your company can and should pay).

Well let's begin.

Mistake 1: thinking DDD === Hexagonal Architecture

It's very common. I have a project, I write three folders under my source folder like this:

    ├── src
    │   ├── Application
    │   ├── Domain
    │   └── Infrastructure

and I call it a day. Hey I am doing DDD!

Well no, you are stating your intention on using hexagonal architecture, which is always a good thing, but that by itself is not DDD.

Hexagonal architecture, in my opinion, is the only way to go, for every project. DDD works very well with hexagonal architecture, it's the best way to protect your domain, and the easiest way to realize where each piece of logic goes: oh that's business! goes to the domain, oh! that is about infrastructure, then it goes to infra. But, while using hexagonal architecture is a good start and something that will save you of many headaches in the future, it's not the same as doing Domain Driven-Design.

In other words, DDD is very hard to do without hexagonal architecture, but you can have hexagonal architecture and not having DDD at all. You can still have a mess in it. Most of the tactical patterns of DDD fall into the Domain layer, so you need to take extra care of that layer.

You should start with that layer, coding all the business logic, and then show via tests how all of this logic is being executed. How the domain is being executed. Even better if you start with the test. And unit tests should suffice for that! You need to make sure the infrastructure doesn't creep all the way to the domain and try "broom inwards" to the inner layers all what could be considered business logic. So the separation of concerns is clear.

Even if you are applying properly hexagonal architecture, you can still have something that looks more like a CRUD application than something done via DDD. It's all about the Domain, if your domain is not rich and what you simply do is just CRUD operations on some half-baked entities that will eventually become meaningless, you might as well give access to the DB to the end user, and you'll save lots of hours!

Mistake 2: overly modular directory structure

For some reason, I see this quite often. And I frankly don't get it. It's overly complicated! And it gives the wrong intent by the programmer. This is what I am referring to:

    ├── src
    │   ├── User
    │   │   ├── Application
    │   │   ├── Domain
    │   │   ├── Infrastructure
    │   └── UserRoles
    │   │   ├── Application
    │   │   ├── Domain
    │   │   ├── Infrastructure
    │   └── Role
    │   │   ├── Application
    │   │   ├── Domain
    │   │   ├── Infrastructure

Well, that would make sense in the case you are looking forward to split this code base into different services, so you are preparing yourself for it. But what is clear out of it, is the complete disregard of the domain! Again people focus on the technical details and forget that DDD is. all. about. the. domain.

On the example it's obvious that User and Roles are highly related. They should probably belong to the same subdomain. And while there might be exceptions, a subdomain should be a bounded context, meaning a service - microservice or application if you want. Would you add a different infrastructure in the same service?

This might even break aggregate rules! One transaction per aggregate. If you just go and split each entity and make it a "service" you are forgetting that maybe they belong to the same aggregate! You definitely are in for a lof of pain. Microservices work on the premise on information hiding, if you have an aggregate defined in different services, you would want to break this principle...

I don't understand why this became such a practice. (I am afraid it's because of some public repos of codely.tv taken out of context, or people used to the horrible laravel's ORM eloquent). But you don't want to make a service per entity, you want to make a service per subdomain. A service - or microservice, application- per entity will for sure lead to a CRUD practice, and eventually to an anemic domain and for sure to a distributed monolith.

All of this belongs to the strategic patterns of DDD. Showing this directory structure implies that each of those are bounded contexts and that you expect them to work totally independently of each other. Again, we need to have the Domain in the heart of our mindset, is that really the case or not? It's ok, and you should, put all the related aggregates in the same bounded context. Maybe you will see that you can split the bounded context further to ease the cognitive load. But you start from a big group and split it. You don't start with everything split by default, and then you join it, uf, that will be a lot of pain...

Mistake 3: CRUD implementations

This is kind the sum of mistake 1 and 2. You can have a very well understandable code in hexagonal architecture, divided nicely in modules per aggregates but with an anemic model that only does CRUD operations.

When I started working in a new company I was rudely told by a colleague "oh I did that in DDD it should be understandable". Seeing CRUD operations on an entity doesn't really explain the business logic. As easy as it can be to maintain it since it's in hexagonal architecture. To explain them you'd better use tests that execute the domain. Even some acceptance tests (the ones that test acceptance criteria) could be simply unit tests.

CRUD operations is almost a synonym of an anemic domain, which is the opposite of a rich domain. Guess which one DDD prefers, having the word "Domain" at the core? Yes, rich domain. An anemic domain is easy to degenerate. You will have meaningless boxes that can either be apples or pears. In that case, you might as well give admin access to the DB to the end users.

It always pays off to make an effort at avoiding CRUD verbs, you will soon realize that your domain is, indeed, more complex than just doing CRUD operations, the move to Event Driven Architecture will be smoother also, having domain events that make actual sense to business, not to databases.

As a side note here, I think that being very dogmatic on RESTful implementations is harmful. REST works very well with CRUD and oh, with active record ORM and anemic domains, so if you have to make very tricky and complicated things just to comply with RESTful principle, I say, ditch RESTful, at least temporarily, you might realize later how to solve it. The dogma of a rich domain should trump the dogma of a RESTful API. I have seen codebases degenerated into un-understandable messes just in an effort to keep RESTful.

Mistake 4: concealed logic at the infrastructure layer

Here is where the hexagonal architecture will pay off. It will be very easy to identify that. The problem is that is difficult to keep strong and to not succumb to the temptation. The alternative is also a lot of work! But well, you know, it should be! and business people should be aware of it, that features have a price and high quality code has too.

So what is this logic? The most common case would be this one, have you ever seen this: @Gedmo\Mapping\Annotation\Timestampable ? You magically add "createdAt" and "updatedAt" fields to the entity, and you forget about it. As I said, it's easy, and the alternative? do it yourself. But you should. Does business need to know when this entity was createdAt or updatedAt? (also, those are CRUD verbs, not a good path) Does the domain need to work with that? If yes, put it where it belongs, in the domain! The entity should have attributes/value objects that indicate this information.

Yes it's a lot of work, but worth it! And if the domain doesn't care, then it's OK to leave it? It's extra information! Well no, it's not OK. Main issue is that it might fail when you retrieve or save a perfectly fine Domain object to the DB because it doesn't comply with logic that is "hidden" in the DB layer.

All the foreign key checks on the Database? well, I'd recommend to get rid of them, the infrastructure layer should be free of business logic, if aggregates have relationships, state that clearly in the Domain code, the infrastructure won't have other choice than to follow. Map the aggregates to the DB as simple as possible. You will see how easy it will be if you ever want to change to NoSQL if you have all the business logic on the domain! As soon as you allow logic on the DB, you will have the domain split in different layers, breaking the hexagonal architecture.

Other examples are making an entity sluggable or even translatable! it might not look like it, but try to bring everything to the domain layer, so infrastructure/application layer are thin and dumb.

That means also that the latest technology and cool stuff, well, it doesn't belong to the domain, so you can make use of it, but on the layer it belongs. You will thank me when you need to upgrade the version of that latest technology.

Mistake 5: leaving domain for the last.

Well, I hope you can see that this is much of the same, all above (maybe except #4) are symptoms of this one. On Domain-Driven Design guess what comes first? Infrastructure? if that were the case don't you think it would have been named infrastructure-driven design? So yeah, Domain comes first.

What does that mean? That you need to speak a lot with business, or the product owner needs to speak a lot with business, or have things very very clear, so you can start modeling the domain first. And you need to speak a lot, communicate a lot, ask questions, maybe even show the code, explain the tests, are we speaking the same language and on the same page? All of that comes first, the rest follows.

And that comes first, is also what will probably evolve the most, will change the most. Imagine if you have it all in a single place and not all spread everywhere how easy it will be to maintain it?

When designing the domain is when DDD truly shines, it might not be easy, and as said, it will change, either because needs change or because we did such a terrible job at the beginning that we need to change it! Making proper use of Value Objects, entities, aggregates, applying design patterns here, it all makes sense, and it's pretty.

If you don't care about the domain, you're making sure you're having a bad design out of it. I was also told "no, in this project there's no domain". Oh, that's impossible, there's no attempt at designing it, which means a terrible design, since there's no such thing as "no-design". As the red book says, that means it's a bad design.

Final words

DDD is all about the domain. A rich domain. I hope that by pointing out this common mistakes, you get a general sense on the proper angle to approach problem-solving.

I would like to finish saying that DDD and Hexagonal architecture are great, but they are not silver bullets. There's a more important thing than DDD when coding, something conveyed on Clean Code by George.R.R. Martin, I mean, Robert C. Martin commonly known as Uncle Bob. (I just had to google them, I had the idea in my mind that they were physically similar, but not at all). The idea is that when coding you should strive for making yourself be understood.

You should strive always for simplicity (and control, I hate the no-code thing, if you like that, just go and become a "website builder" from Drupal, and leave the actual work to the "smart people"). Don't be afraid of hard work. The code with more "WTF" per second I've seen, it's been always something written by somebody that thought what was written was very smart. Oh, it was indeed, but, if you have a message to convey, would you encrypt it, or would you make sure that it is as easy to understand as possible?

We are doing complicated things, let's not make them more complicated than they need to be...(except when you try to be funny, it's forbidden by Uncle Bob on Clean Code, but a pun in a specific place can make for a very expensive joke!)