4 ms·

I think I learned more about what DDD is from this article than most of my books on DDD. This is the right way to do a critique -- it starts out with an excelle

I think I learned more about what DDD is from this article than most of my books on DDD. This is the right way to do a critique -- it starts out with an excellent Steel Man understanding of DDD and proceeds from there. I guess they don't make em like they did in 2018 anymore!

onli 2y ago
There are some things in there I did not exactly get. Mainly, if every class has its own table, and database operations are all so similar, is the software produced not only a collection of very simple mechanical operations? How could there be any value in that? But there are good things there - data first for example, and the correct identification of interfaces - which will help avoid useless indirections often misunderstood as abstraction.
- rowanG077 2y ago
  I think you are conflating technical complexity with value. There are a ton of things where a simple app you describe brings value. They even have a specific name CRUD apps.
  - onli 2y ago
    Fair enough, the comment certainly did. But the message or question was more supposed to be about that a simple crud app does not need a big methodology anyways, and that DDD isn't meant for that in the first place (iirc building a simple crud app is a reason not to use DDD, at least in one of the main books). I'm aware that sometimes simple software can have a lot of value.
- motorest 2y ago
  > Mainly, if every class has its own table, and database operations are all so similar, is the software produced not only a collection of very simple mechanical operations? How could there be any value in that? DDD does not have the concept of a table or database, let alone requires it. There's some degree of confusion expressed in your comment. In a somewhat simplistic explanation, Domain-Driven design focuses on creating a model of the application domain, and with that define the necessary and sufficient operations that implement your requirements. All your operations are implemented in terms of your domain model. The tricky part is putting together a domain model that's consistent and doesn't allow the system to generate invalid data or be left in an inconsistent state. This leads us to the concept of root entities, and on top of them use aggregates to express transactions that involve multiple entities and values.
  - onli 2y ago
    Not talking about DDD here, but the linked article describes this as his alternative approach.
- d0mine 2y ago
  Somewhat unrelated: Value has nothing to do with complexity, effort on your part, etc. Imagine you have a customer who needs X, you can do it in Y days today but tomorrow another customer might require X’ (something very similar to X) and now you can deliver it in Z << Y days (eg by reusing a framework developed for X). Value of X, X’ to the customer may be very similar despite your effort Y, Z drastically different (junior dev shouldn’t charge more just because it might take them longer).
- epolanski 2y ago
  > is the software produced not only a collection of very simple mechanical operations? In the context of mostly crud operations unsurprisingly yes. The value lies in knowing where and how you'll find the relevant pieces you need to touch to e.g. add new features or extend business rules, without ending up putting business logic in the wrong place (such as misplacing it in a service responsible for communicating with the db e.g.).
Joel_Mckay 2y ago
In general, I observed a few programmers that are keenly aware of their skill set, and tend to complain loudly about systems that hold people accountable by colocating their bad workmanship with their area of responsibility. The secret of bolting on a good AMQP pattern is embedding signatures, GUID, UTC time, and expected state pre-conditions. The notion a problem domain even fits into a monolithic structure is laughably naive. Usually, toy naive designs devolve into a dynamic object storage model on SQL, and it is ridiculously silly in this age. Best regards =3
epolanski 2y ago
It doesn't help that DDD like most OO-related theory is very poorly defined. It's also something that pushed me towards functional programming, I could finally understand concepts by understanding their definitions.
pyrale 2y ago
That’s not good news, because this article is dead wrong about many ddd concepts. For instance, the very first list item: > DDD is against the idea of having a single unified model Is wrong: DDD is not against the idea of an application having a single unified model. Bounded contexts exist to help you understand the organization, and, specifically, that different people may use the same word with a different meaning. But if your application serves a single group in the company where definitions are shared, there is no reason for your code to leverage multiple bounded contexts, and their existence may be limited to a footnote in the project’s business glossary doc.
- epolanski 2y ago
  Your counter opinion kinda confirms the issues with stuff like DDD being consistently open to interpretation. Not surprising, it lacks clear and rigorous definitions and almost everything is example-driven. It's like lacking both the rigour of academia, and the practicality of seasoned engineers at the same time.
  - pyrale 2y ago
    The same is true of every interesting concept in dev, unfortunately: design patterns being made into a pokedex, agile into an inflexible process, hexagonal arch into a guideline for project directories’ names and layout, metrics into goals, etc.
- upghost 2y ago
  Come come now. That's the very first bullet point of the article. The article did a very good job of giving DDD its due. I don't think it's fair that the article went out of the way to define what it meant by DDD in a Steel Man fashion and this response attacks the first and easiest to attack point of the article in a Straw Man fashion! In fact, the comment I made wasn't even about DDD, it was more about how I appreciated the construction of the argument. Agree or disagree (I happen to be a fan of DDD) I learned a lot from the article and I wish more articles were constructed like this.
  - 2y ago
namaria 2y ago
"Steel man" doesn't sound like the opposite of "straw man". It just sounds like a more resource intensive version.

onli 2y ago

There are some things in there I did not exactly get. Mainly, if every class has its own table, and database operations are all so similar, is the software produced not only a collection of very simple mechanical operations? How could there be any value in that? But there are good things there - data first for example, and the correct identification of interfaces - which will help avoid useless indirections often misunderstood as abstraction.

rowanG077 2y ago
I think you are conflating technical complexity with value. There are a ton of things where a simple app you describe brings value. They even have a specific name CRUD apps.
- onli 2y ago
  Fair enough, the comment certainly did. But the message or question was more supposed to be about that a simple crud app does not need a big methodology anyways, and that DDD isn't meant for that in the first place (iirc building a simple crud app is a reason not to use DDD, at least in one of the main books). I'm aware that sometimes simple software can have a lot of value.
motorest 2y ago
> Mainly, if every class has its own table, and database operations are all so similar, is the software produced not only a collection of very simple mechanical operations? How could there be any value in that? DDD does not have the concept of a table or database, let alone requires it. There's some degree of confusion expressed in your comment. In a somewhat simplistic explanation, Domain-Driven design focuses on creating a model of the application domain, and with that define the necessary and sufficient operations that implement your requirements. All your operations are implemented in terms of your domain model. The tricky part is putting together a domain model that's consistent and doesn't allow the system to generate invalid data or be left in an inconsistent state. This leads us to the concept of root entities, and on top of them use aggregates to express transactions that involve multiple entities and values.
- onli 2y ago
  Not talking about DDD here, but the linked article describes this as his alternative approach.
d0mine 2y ago
Somewhat unrelated: Value has nothing to do with complexity, effort on your part, etc. Imagine you have a customer who needs X, you can do it in Y days today but tomorrow another customer might require X’ (something very similar to X) and now you can deliver it in Z << Y days (eg by reusing a framework developed for X). Value of X, X’ to the customer may be very similar despite your effort Y, Z drastically different (junior dev shouldn’t charge more just because it might take them longer).
epolanski 2y ago
> is the software produced not only a collection of very simple mechanical operations? In the context of mostly crud operations unsurprisingly yes. The value lies in knowing where and how you'll find the relevant pieces you need to touch to e.g. add new features or extend business rules, without ending up putting business logic in the wrong place (such as misplacing it in a service responsible for communicating with the db e.g.).

Joel_Mckay 2y ago

In general, I observed a few programmers that are keenly aware of their skill set, and tend to complain loudly about systems that hold people accountable by colocating their bad workmanship with their area of responsibility. The secret of bolting on a good AMQP pattern is embedding signatures, GUID, UTC time, and expected state pre-conditions. The notion a problem domain even fits into a monolithic structure is laughably naive. Usually, toy naive designs devolve into a dynamic object storage model on SQL, and it is ridiculously silly in this age. Best regards =3

epolanski 2y ago

It doesn't help that DDD like most OO-related theory is very poorly defined. It's also something that pushed me towards functional programming, I could finally understand concepts by understanding their definitions.

pyrale 2y ago

That’s not good news, because this article is dead wrong about many ddd concepts. For instance, the very first list item: > DDD is against the idea of having a single unified model Is wrong: DDD is not against the idea of an application having a single unified model. Bounded contexts exist to help you understand the organization, and, specifically, that different people may use the same word with a different meaning. But if your application serves a single group in the company where definitions are shared, there is no reason for your code to leverage multiple bounded contexts, and their existence may be limited to a footnote in the project’s business glossary doc.

epolanski 2y ago
Your counter opinion kinda confirms the issues with stuff like DDD being consistently open to interpretation. Not surprising, it lacks clear and rigorous definitions and almost everything is example-driven. It's like lacking both the rigour of academia, and the practicality of seasoned engineers at the same time.
- pyrale 2y ago
  The same is true of every interesting concept in dev, unfortunately: design patterns being made into a pokedex, agile into an inflexible process, hexagonal arch into a guideline for project directories’ names and layout, metrics into goals, etc.
upghost 2y ago
Come come now. That's the very first bullet point of the article. The article did a very good job of giving DDD its due. I don't think it's fair that the article went out of the way to define what it meant by DDD in a Steel Man fashion and this response attacks the first and easiest to attack point of the article in a Straw Man fashion! In fact, the comment I made wasn't even about DDD, it was more about how I appreciated the construction of the argument. Agree or disagree (I happen to be a fan of DDD) I learned a lot from the article and I wish more articles were constructed like this.
- 2y ago

namaria 2y ago

"Steel man" doesn't sound like the opposite of "straw man". It just sounds like a more resource intensive version.