Comment by rockyj | Hacker News Reader

Comment by rockyj | Hacker News Reader

This article provides a lot of validation from my own experience. I was always weary of DDD fanatics, I always thought I was not bright enough to understand statements like -

- In domain-driven design, the Domain layer is one of the common layers in an object-oriented multi-layered architecture.

- DDD is against the idea of having a single unified model; instead it divides a large system into bounded contexts, each of which have their own model.

I do not know what these mean and I have found no real good explanations. In my 20+ years of experience I have not seen any problem which is solved elegantly with DDD based development and/or CQRS etc.

My simple rule of new tech / random things such is these is - what is the adoption rate and what are the major success stories. With technologies like RoR, React, Spring Boot, Kotlin etc. it is easy to see the reason for their adoption and success. I have heard no such stories for DDD. In fact, I have found the developers which advocate these have been the hardest to work with (rich on theory and opinion and poor in actual written software).

> DDD is against the idea of having a single unified model; instead it divides a large system into bounded contexts, each of which have their own model.

If you have a large system it makes sense to divide it into smaller independent pieces. If you have a (micro)-service architecture you have distinct services, in a monolith you might have modules.

It is a hard problem to know where exactly the boundaries between services or modules should be, in any case DDD calls the things that make sense to decouple bounded contexts.

CQRS is great, (but I've not heard it linked to DDD before this article.)

If you have an SQL schema and your domain is money, some numbnuts is going to get the rounding wrong, accidentally calculate with floating point, forget to store currency, forget what the minor unit of each currency is, mix up credit/debit, and/or use a negative sign when there's an agreement not to.

You won't find out about the mistakes until after you've been running in prod for a while. And fixing the code won't fix the problem, because you only find out about the bad code after you've already produced bad data. But you still have to struggle to fix the bad code anyway. Use migrations to introduce new columns, while the system is running, etc.

What if instead of everyone updating one central table in-place, they just put their updates into some persistent queue, in some loose json format? If you were to keep that data around, you could at any time create new SQL tables and populate them from the source data. You could even afford to get it wrong a bunch of times, because you can throw away the tables.

Event sourcing? I thought that was a very DDD thing.

Reply on news.ycombinator.com