Thanks to author for topics explanation. But that was just a tiny spot of what's happening in DDD. And this is more about an implementation of common enterprise app, than DDD itself.
Typical example of over-architecting by consultants. DDD on front-end is unnecessary and makes thing more complicated. Most of the frameworks such as Angular, React have their own design patterns and sticking to them(say Angular's SOLID priniciples, REDUX, NgRx) makes the code very well maintained. The real problem with the DDD is when the backend "solution architects" start overthinking. This is from my personal experience. UI will most likely, if not always, have to integrate information from multiple domains. So segregating UI according to domains, make little sense. It breaks the natural structure of the project and makes thing messy. And keeping domain logic on both the frontend and backends is just seems like a stupid idea as well. Just having a modular structure, following SOLID principles and organizing according to business logic is more than enough.
I arguably disagree. There is always room to pick the good part of each architecture pattern and apply it to your software, whether UI or pure backend. For example, an app with over 400 screens and more than 15 teams working on it in several departments to deliver different features will definitely need way more structured architecture than an app with only 20 screens. What you say is definitely true for smaller apps. However, I still believe what you said is perfect makes sense. Therefore, I iteration over this talk where I introduced straightforward architecture for the simpler app, which addresses your concern comment above. In fact, ubiquitous language and having bounded context are not something you should only do in backend and enterprise apps. It can work perfectly in the smaller app, as it will unify the development team and product and business team. I have seen so many confusions during my career where only a language led to a bug and introduced issues. Lastly, I really appreciate your feedback. It's very nice to hear everyone's feedback because I can improve and have a better talk. Please reach out if you want to discuss more with me twitter.com/mhadaily
at 34:20 you hear @resocoder asking his question. 🙂
I knew it was him! I've just come from a video he promoted a Flutter Europe conf, than I was almost sure, then I read your commet
Great talk with a bit of asmr
Thanks to author for topics explanation. But that was just a tiny spot of what's happening in DDD. And this is more about an implementation of common enterprise app, than DDD itself.
why is the bloc in the presentation layer? Isnt it supposed to be in a seperated bloc layer
Agree. It should be in the appplication layer. Maybe his version is a simpler ddd
Awesome, thank you
Very helpful and useful talk, thank you
Hi. Please upload Felix speaking about Bloc.
Loved this talk.
how to functionally provide left or right of future of widget pieces from infrastruchure? < --- is question or answer
it was practical. thanks
Thanks you!
can i get sample github source code to learn? please share me some sample codes if you have. thanks.
Search flutter with ddd and redux + github
Typical example of over-architecting by consultants. DDD on front-end is unnecessary and makes thing more complicated. Most of the frameworks such as Angular, React have their own design patterns and sticking to them(say Angular's SOLID priniciples, REDUX, NgRx) makes the code very well maintained.
The real problem with the DDD is when the backend "solution architects" start overthinking. This is from my personal experience. UI will most likely, if not always, have to integrate information from multiple domains. So segregating UI according to domains, make little sense. It breaks the natural structure of the project and makes thing messy.
And keeping domain logic on both the frontend and backends is just seems like a stupid idea as well. Just having a modular structure, following SOLID principles and organizing according to business logic is more than enough.
Thank you
I arguably disagree. There is always room to pick the good part of each architecture pattern and apply it to your software, whether UI or pure backend. For example, an app with over 400 screens and more than 15 teams working on it in several departments to deliver different features will definitely need way more structured architecture than an app with only 20 screens. What you say is definitely true for smaller apps.
However, I still believe what you said is perfect makes sense. Therefore, I iteration over this talk where I introduced straightforward architecture for the simpler app, which addresses your concern comment above.
In fact, ubiquitous language and having bounded context are not something you should only do in backend and enterprise apps. It can work perfectly in the smaller app, as it will unify the development team and product and business team. I have seen so many confusions during my career where only a language led to a bug and introduced issues.
Lastly, I really appreciate your feedback. It's very nice to hear everyone's feedback because I can improve and have a better talk. Please reach out if you want to discuss more with me twitter.com/mhadaily
slow and boring
no, he was the best