Strategic Domain-Driven Design for Improving Flutter architecture - Majid Hajian | Flutter Europe

Architecting software, especially on a large-scale where it needs to meet the business requirements is always a challenge and Flutter apps are not an exception. Strategic Domain-Driven Design techniques ensure your application is optimized to support business goals while identifying cohesive modules, known as a bounded context which creates a maintainable, comprehensible codebase by isolating dependencies and describe business value. In this talk, I explore the idea of the ubiquitous language, bounded context, sub-domains while they are being implemented in a real application. All in all, You'll learn how I attempted to architect a (large-scale) Flutter application by technical solutions and appropriate methodology in order to have a sustainable app.
Speaker: Majid Hajian ( / mhadaily )
****************************************************
Flutter Europe → fluttereurope.dev
Follow us on Twitter → / fluttereurope
Follow us on Facebook → / fluttereurope
All talks → • Flutter Europe talks
****************************************************
Learn Flutter → flutter.dev

[@easazade]

at 34:20 you hear @resocoder asking his question. 🙂

[@regis2480]

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

[@svetozarvolkov5953]

Great talk with a bit of asmr

[@monklg]

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.

[@samrystrom3532]

Awesome, thank you

[@mshanak1]

Very helpful and useful talk, thank you

[@kedeedoman5453]

Loved this talk.

[@KenanYusubov]

Hi. Please upload Felix speaking about Bloc.

[@snip4yt]

why is the bloc in the presentation layer? Isnt it supposed to be in a seperated bloc layer

[@JamesReubenGruta]

Agree. It should be in the appplication layer. Maybe his version is a simpler ddd

[@nattajab]

Thanks you!

[@easazade]

it was practical. thanks

[@ankitlakum1]

how to functionally provide left or right of future of widget pieces from infrastruchure? < --- is question or answer

[@phyo936]

can i get sample github source code to learn? please share me some sample codes if you have. thanks.

[@ankitlakum1]

Search flutter with ddd and redux + github

[@mathstracted9302]

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.

[@tesfahunkebede208]

Thank you

[@mhadaily]

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

[@evgeniykalaganov6753]

slow and boring

[@squidproxy136]

no, he was the best

[@suranjithnishalaka7395]