Hacker News Reader

Comment by c048 | Hacker News Reader

While I can get behind hexagonal architecture quite well, the more I use DDD the less I like it. It feels like doing DDD correctly is immensely difficulty, time consuming, makes code harder to read, etc... .

While everyone seems to want to do DDD, I've seen so many different approaches to it that always seem to slow down the projects as time moves on, because it becomes a constant struggle with the architecture. And for what? Benefits like a clear domain language that can be shared with the business does not require DDD. Most (if any) projects feel like they are ill fit for DDD.

"Ah, but that means you're doing DDD wrong!", I can already imagine a few people say. But I'd like to see one agreed upon approach to DDD that works when things start to get complex, rather than another super simple example that's supposed to sell you on the idea.

View on HN

All these architecture and workflow methods (Agile, scrum, TDD, DDD, Kanban, even 12-factor) have a few useful and logical concepts at their base. Then people create a dogmatic religion around them, often without even understanding the why.

An experienced and reasonably intelligent person usually has no difficulty in figuring out which concepts are most relevant for a given project to increase its changes of success. In reality, that person just ends up fighting adherents of the chosen corporate or hive-mind dogmatic religion or finds themselves surrounded by people in pure ignorance of matters beyond throwing code over the proverbial wall.

You should not "follow" agile or DDD. You should understand its concepts and apply them when suitable, as part of a broad toolkit – as with anything in life.

There's a book called "Cosmic Python", which gave me a clear basic intro to DDD, though not being a DDD book itself.

https://www.cosmicpython.com/book/chapter_01_domain_model.ht...

> In a nutshell, DDD says that the most important thing about software is that it provides a useful model of a problem. If we get that model right, our software delivers value and makes new things possible.

> If we get the model wrong, it becomes an obstacle to be worked around.

This was painfully true at my last company, and we failed to prioritize naming and modelling. I regret I did not know enough to point out explicitly what was wrong. It could have saved a lot of confusion and on-boarding costs.

I still haven't applied this book fully, but I've certainly taken good ideas from it.

If you want to support it there are many ways to do so: https://www.cosmicpython.com/

The main point is that language you use to talk business should be used to write code. I don't get how using ubiquitous language can slow down the projects.

> clear domain language that can be shared with the business It does not work like that. Business share their lanaguage with you, not other way around.

Most important thing in DDD is Domain Expert. He's the cental point of strategic DDD. If you don't have one, then you either have CRUD app (which you shouldn't use DDD for - stick with ADM) or you can just use something called "DDD Lite" which is often referred to as "OOP done right".

Also, main problem w DDD (or any architectural approach) is that you have to make biggest architectural decisions when you basically have the least amount of knowledge about the system/problem.

>I don't get how using ubiquitous language can slow down the projects.

It doesnt. Ubiquitous language is more or less just a reworking of system metaphor from XP and was a fine idea even then but DDD took the idea, barely tweaked it and layered a bunch of quite horrible design patterns around it.

Ubiquitous language and bounded contexts are the best parts of DDD by far but theyre also the least original and the least well developed concepts and honestly DDD doesnt have much of anything interesting to say about either one of them beyond what they are and that theyre important.

I wish I could upvote you more than once. You hit the nail on the head, thank you.

I think this is the impedance mismatch between the intellectual and the practical all over again.

More and more, when I find myself at odds with people it’s because one of us is trying to intellectualize a situation that cannot be safely intellectualized. Not that we have changed, but that my perspective has changed.

In disciplines with more physicality, “exercises” are used quite often and routinely denoted as being an artifice. Not all instructors do and not all students listen, and so YouTube is full of videos of martial artists getting their clocks cleaned for mistaking forms for sparring, sparring for fighting. Consultants recording/cleaning up construction or landscaping disasters created by ignoring the rules - or failing to think outside of the box. You could spend the rest of your life watching these kinds of videos and not see half of them.

I don’t want to do TDD all day every day. It’s infantilizing. But I’m a better developer for having done it, and when I feel the consequences starting to add up, I will do it again for a time, to knock the cobwebs off. You probably feel the same about DDD.

DDD is about building maintainable software by trying to separate the business domain from the application technology. If there is no separation and/or the software is not easy to maintain(more than just being tired of looking at it year after year), then try something else.

Reply on news.ycombinator.com