4 ms·

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 prod

by 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.).

by onli 2y ago

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.).