also (more general):
because every frontend dev thinks their codebase is modular and yet 3 years later the same peopleconsider it legacy legacy and want to rewrite it from scratch?
But Thomasz, you write that DDD is about collaboration and communication. While now you are talking about technical aspects like modularity and maintainability. I don't understand.
Tomasz, I think I read your previous material not so long ago. My difficulty is that the treatment was so general, abstract and imprecise, that it is difficult to phrase exact questions. So an exact question is: how does DDD relate to SE engineering activities for front-ends?
We had this discussion already recently :) I still strongly claim that if you do DDD in the front-end, then logic leaked into it from thr back-end. If it's not really a front-end but a fat client, then no problem. Otherwise, the basic rule of separating (business) logic and UI is broken.
Also, please explain more exactly what you mean by DDD in the front-end before promoting it like it's a self-explanatory and most logical thing to do. Is it like having a domain model in the front-end, "aggregates", something else?
I am asking because the linked article starts by stating that DDD is about communication and collaboration. This is so general and, frankly, trivial, that it can't be an answer. Of course people communicate and collaborate in engineering work.
Comments
Should I continue?
because every frontend dev thinks their codebase is modular and yet 3 years later the same peopleconsider it legacy legacy and want to rewrite it from scratch?
I'll happily discuss, let's start with making questions more precise.
BTW what is your background?
No, no aggregates on frontend. Nearly no tactical DDD on frontend whatsoever.
Sand yes, domain model - yes.
But one doesn't equal the other.