Thanks for this post. I think it is important to talk about Domain Driven Design, to study and study again, to put it into practice because it is not simple, it is not something simple just because it tries to express needs in the most adherent way to reality through software, but, at the end, it's really worth it
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
As you mentioned, talking and practicing DDD is vital for software engineers. We should keep in mind that usually, only a little subset of our system requires DDD. I think no more than 10-15% of the whole system. There is no sense to apply DDD to places where only simple CRUD is needed. That ends with so-called "over-engineering". Of course, everyone makes mistakes during the learning process. In my opinion, Domain Driven Design is worth this.
"it depends" is always a good starting point, in my opinion. But I'm sure that, for modern and complex systems, using only CRUD operations could lead to excessive and sometimes unmanageable complexity. It's a trade off: "forcing to follow this path" or "over-engineering" to better understand the code and keep its complexity under control over time is always worth it, but sometimes in our working environments this point of view is not fully accepted or understood: timing and costs are the greatest constraints
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
Thanks for this post. I think it is important to talk about Domain Driven Design, to study and study again, to put it into practice because it is not simple, it is not something simple just because it tries to express needs in the most adherent way to reality through software, but, at the end, it's really worth it
Thanks for good words :)
As you mentioned, talking and practicing DDD is vital for software engineers. We should keep in mind that usually, only a little subset of our system requires DDD. I think no more than 10-15% of the whole system. There is no sense to apply DDD to places where only simple CRUD is needed. That ends with so-called "over-engineering". Of course, everyone makes mistakes during the learning process. In my opinion, Domain Driven Design is worth this.
"it depends" is always a good starting point, in my opinion. But I'm sure that, for modern and complex systems, using only CRUD operations could lead to excessive and sometimes unmanageable complexity. It's a trade off: "forcing to follow this path" or "over-engineering" to better understand the code and keep its complexity under control over time is always worth it, but sometimes in our working environments this point of view is not fully accepted or understood: timing and costs are the greatest constraints
I totally agree with you. I ’m also a big fan of the ”It depends” clause. We should ask if we need something in our solution.