Flutter Firebase & DDD Course [1] – Domain-Driven Design Principles

firebase allows developers to get their abs working quickly and flutter does the same thing but as it goes in life trade-offs are everywhere sure you can hack something together in a dash of enthusiasm but this initial excitement will fade away as soon as you get totally lost in your own code flatter abs need structure that is easy to orient yourself in testable and maintainable it also wouldn't hurt if the way you architect your flower apps allows for adding new features without having a severe headache especially with client centric services such as firebase firestore it's extremely important to keep your code clean so let's do it by following the principles of domain driven design in this tutorial series [Music] hello welcome to resew code where you are getting prepared for real app development so that you will get freelance clients or a job and be confident about the apps you build so subscribe and hit the bell to join us on our quest for becoming in demand flutter developers before we hop into the explanation of what is domain driven design and how can we apply it to our flower apps let's take a look at what we are going to build throughout this tutorial series we are going to build a pretty substantial app using firebase firestore and firebase authentication and it's going to be a note-taking app so here we have a note of important things which we should do immediately so after you like and share this video subscribe to reso coder you can then also learn from the written post and we have to stick to off all of these two do's we can now save this note and you will see that this note is now present here we can antek something although don't unsubscribe from reso coder that's for sure and when we antique these two to Do's they're now going to be also an ticked in this overview of the do's and also if we go here to this last note and we update it for example let's say that we have already read Plato's Republic right we can also change its color to be red maybe when we do that this last note will now be updated which means it will be sorted as the first note right over here is now first in the list of all notes we can then also show only the notes which are not yet completed so because this first note is now fully completed all of its two dues are checked off when we filter by non completed the first no will go away and also this second last note will go away too so this is what we can do with notes we can of course also add new notes and if we leave for example to do empty it's going to say that it cannot be empty so we need to input something in the same goes for the note body we cannot leave it empty because it's just going to provide us with an error message right here right we cannot possibly have it empty because we are not even going to be able to save anything to the database unless the data is fully valid so that's nice and also we cannot have more than three two deuce we're gonna be otherwise prompted to activate premium so yeah the premium buying is not implemented but yeah you can at least this premium upgrade message is implemented and once we have all of the to do is fill then also the note body is fill then we can select the custom color for the note and this note will be added to our list of notes awesome so this is what we can do with the notes but of course this app would not function without authentication because all of these notes are persisted to fire stored so we can lock out from this app by clicking this button and we're gonna be taken to the sign-in page where we can either sign in with Google or with an email and password then we can also register so again you cannot leave the email and password fields empty when we enter an email three so Korra calm and an invalid password right sign in it's gonna tell us that invalid email and password combination was entered also when we leave the email to be something invalid it's automatically going to say invalid email and when we fill it in again to be valid so record com it's going to hide this error message when we try to register with an email which is already registered it's gonna say email already in use and now when we finally sign in with the correct password we are gonna be presented with the notes we had there even previously and we can of course also sign in with Google with my ad reso Cora calm email and we're gonna be presented with the same notes so this is the app we're going to build this was an extensive overview of all of this we're gonna build it throughout this tutorial series so make sure you stick till the end and now let's actually go through what is domain driven design what is the big picture and how this app is going to be implemented the term domain driven design may bring new shippers and the same may be said about the term architecture but actually architecture is something which is very beneficial to any sort of a software project you can take on yourself that's because without proper architecture the your code will start falling apart you will now be able to maintain it you will not be able to test it and overall it's going to become one huge mess which is pretty hard to clean up down the road so you have surely built fire abs or at least seen some far apps being built with firebase authentication and fire stored and you may also have built some apps using a REST API so you performed some HTTP requests and even then you surely did not put all of your request code into your flatter widgets layer I hope at least you at least separated out your code using change notifier or maybe you used block or even something else so this means that even before you use some sort of an architecture right and what we are going to do in this series is that we are going to not use just some sort of an architecture but instead we are going to use a serious sort of an architecture and you can see this overview right over here also I would highly recommend you to check out the written tutorial from the link in the video description where you can find this full write-up of what I am about to tell you in a written form and you can go through this at your own pace because this first part of this tutorial series will be fully packed with information which will probably be quite new to you so really if you want to go through this at your own pace take notes highlight something and understand this fully go ahead and click the link in the video description and learn from the written tutorial also you may have seen my clean architecture series on this channel and over there we had some sort of an architecture this one will be pretty similar but it's gonna be also different I'm gonna explain the differences in just a but basically you do not need to worry if you have not seen my clean architecture series because it's not a requirement in order to watch this series you can totally start fresh with this series and you are going to learn everything you need to know as we go so let's go over the basic things which are immediately visible in this diagram so we divide our app into four separate layers those layers are called presentation application domain and infrastructure so you may be already familiar with the presentation layer because that's what is usually meant by flutter flutter really lives in this widgets layer all of the other things are built by us or they are just third-party libraries but the flutter widgets flutter SDK is used only inside the presentation layer we're gonna get to this layer in more detail in just a bit but now let's move on to the next layer to just have a brief overview of it so the next one is application layer and you can see that we are using the term block here and this is what I want to get to before we go into more detail into the separate layers so do not worry if you just hate block and if you have declared your swirled enemy we're gonna use block in this tutorial series but you don't have to I will always explain if there are some differences for when you are using block and when you are not using it for example here when you are using block you're going to have states and events in the presentation layer and you will have block in the application layer if you are not using it but you instead wanna use something like a change notifier or a mob X store or whatever else you will have a view model in your presentation and you will have used cases in your application layer these are the only difference is for when you use bak and when you don't use it you are probably already familiar with most of the terms on this diagram so for example here we have a user who performs touch and maybe even speech events in our case we're going to be only operating with touching on the screen and this goes into the widgets right so usually you have some gesture detectors some buttons and so on and then basically you have events or you call some methods on view models you know about blocks we're gonna get to use cases in a while but what's completely out of this ordinary world of flutter development that's this domain layer right because yeah you have some data sources that's the usual stuff which you should do if you are a decent programmer you are not going to put your data handling logic into the widget code that's really bad if you do it I hope that you don't and also there are blocks like most of the people are at least a bit familiar with the block pattern but this domain layer it just doesn't exist anywhere unless you have watched my clean architecture series but even then inside a clean architecture series this domain layer looked a bit different so what's up with this domain layer well this domain layer is the absolutely most necessary layer and the most central layer of any app it contains entities and validated value objects which are held and sort of composed in those entities and then it also contains failure years without getting too much into the details just yet let me just tell you that the validation you have seen in the emulator so for example the validation in the login screen that we cannot log in with an in with email so if we do not have the dot-com top-level domain we're not gonna be able to sign in its gonna say invalid email and as soon as we add that comm in there the error message will be gone this value validation did not happen inside the UI this validation happened inside a validated value object it's a part of our domain layer it's our business rule and the business rule says that any string which should represent an email address has to have the top-level domain we are using a regular expression to validate an email address and the same goes for password we do not have just any sort of a string in the UI and that is only validated in the UI know we have a value object called password in our domain layer and that value objects job is to make sure that it holds only values string values which are at least six characters long if they are at least six characters long everything is good if we delete the characters it's gonna say short password because there are not six characters right so this is the core distinction the most important differentiator of this domain driven design thing we are gonna be doing in this tutorial series that everything which is a business logic is going to be held inside a domain layer and we are going to encode it in two types we are now gonna pass around strings we are not gonna pass around integers instead we are going to have them be wrapped inside a value object which will validate them so now that we have at least some sort of an idea about what these value objects are doing in our app let's look at the entities entities are fairly simple they just contain a bunch of validated value objects for example if we sign into our app with Google so that it's quicker and we come here this note is an entity and this note holds multiple validated value objects one of them is note body because this note body has an encoded validation logic saying that it has to be not empty and it has to be maximally 1000 characters long then it has a note color validated value object and then it has this to-do list which can have only three items inside of it and every to do cannot be empty right so if we want to leave this empty we're gonna get an error message that just cannot happen oh and by the way we can also woops we can also delete to do this like this so that's also something which we can do max so this whole note is going to be held inside a note entity and that note entity will be comprised of multiple value objects cool I hope so the domain layer is also going to hold any sort of a business logic which is central to our app we're going to get a look at it throughout this tutorial series the last thing I would like to tackle in this domain layer before me move on to other layers are these failures as you know exceptions are thrown around the app left and right you don't know where they originate from you don't know if you are gonna catch them you do not have any idea like what to do with them because they are they can be flying literally from any side and what usually happens is that you have to check the documentation of a math to find out which exceptions can this method throw and then you have to have catch statements multiple ones and really just sketch those pesky exceptions and hope that you didn't forget about anything what if we could change this horrible situation by not throwing exceptions in our app but instead by using failures which are going to be joined into the regular flow of data so just like you return integers from a method or you return entities from a method in our case and validate the value objects from a method you are going to return failures in the same way there will be no separate flow of errors and exceptions by throwing them no all of the exceptional cases are going to be returned from the method in a way that you cannot possibly forget to handle a failure and that you cannot forget about any case of failure and by the way I really recommend you to check out the written tutorial from the link in the video description because there you can really go through all of this information even more in depth and at your own pace so we have just gone over the most differentiating layer of this whole architecture and that's the domain layer this is really the core of your app and this domain layer is not gonna be dependent upon any other layers there are gonna be no dependencies from the domain layer to the outside layers but on the contrary outer layers will heavily depend on the domain layer in one way or the other we're going to again get to the details throughout this whole series you are going to learn everything this first part of this tutorial series is really just a high-level overview so that you kinda know where we are operating I do not expect you to understand everything just yet because yeah there is really a lot to comprehend and as I always preach here the best way to learn is by building projects but you also have to have some sort of a foundation to build off of before you start building project because yeah otherwise it's going to be pretty bad so I need to provide at least some kind of an explanation up front so we have gone over the presentation layer there is really nothing fancy in here it's the usual flower stuff we are all used to so you have states and events if you are using block or you have your change notifier or states rebuild or whatever you have stayed notifier the new package from Remy SLA whatever you have here you are golden this is the usual stuff so we have gone over the domain layer and the application layer well what is it it holds blocks which some of you may be familiar with or it holds some use cases which also some of you may be familiar with you are gonna have use cases here if you do not wanna use blocks and there are links in the written tutorial if you want to learn more about use cases but as I said in this tutorial series we are going to use blocks here the role of the application layer is to orchestrate everything which goes on in the app so you aren't going to find any UI code inside the application layer neither network code will be located here nor any database code nor like anything the only logic inside the application layer is that it's going to take inputs from the presentation layer in this case in the form of events which arrive in the block and then it's going to decide what to do with those events and sort of call repositories to get some data from the outside world it's going to instantiate validated value objects right because block receives raw data but we want to validate that raw data those raw strings so that we can have actually those nice error messages in the UI so the instantiation of these validated value objects will happen inside the block or inside the use cases whatever you want to use in our case the application layer so the blocks will manage subscriptions to the real-time data streams from firebase firestore right because we need to manage those streams so that they're going to be disposed of when we close route in Flour so that we do not get built for unnecessary firestore reads so all of this management kind of stuff will happen inside the application layer but nothing else no business logic is inside the application layer business logic is reserved for the domain layer the application logic holds something called well application logic its sole purpose is to orchestrate the flow of data around the app we've gone over almost all of the layers and what's left now for us to cover is the infrastructure layer if you take a look at this it's closest representation among the other layers which we have gone over is the presentation layer because if you look at it closely this infrastructure layer is at the boundary right it's at the outside of our app and also the presentation layer is at the boundary of our app of course the boundaries are different the presentation layer interacts with the user whereas the infrastructure layer interacts with api's databases and the device sensors like for example location and accelerometer and so on but still it's at the boundary so what this means is that this layer can change pretty rapidly and tremendously so we definitely want to keep this kind of tucked away so that for example if we decide to change from SQLite database for example more to something like no SQL local database called hive or SEM best or whatever you need if we decide to change that which is a pretty substantial change we are now going to need to change anything besides the infrastructure layer where actually we are probably going to only need to change the local data source everything else from the infrastructure layer up will be unchanged and most importantly this domain layer will be completely untouched but let's go nicely bit by bit as you can see the infrastructure layer has really three core parts it has repositories data transfer objects and then also data sources let me immediately mention here that we are now going to touch data sources in this tutorial series because we are actually not really gonna communicate with raw data directly if you think about it we have cloud firestore and also firebase of packages from Google or actually now from the community unfortunately because Google sort of decided to leave it up to the community which is really unfortunate but anyway we have those packages which will communicate with the raw data for us so the firestore class from the cloud firestore package will serve as our remote data source for firestore so what we are gonna do is to operate only with the repositories and with the data transfer objects the data sources are gonna be kind of hand for us so what are data transfer objects their sole purpose is to convert data between entities and value objects from the domain layer and plane data coming from the outside world because the outside world will of course not have any sort of validated data it's just going to be simple JSON probably simple strings simple integers and boolean and we wanna take their data and fit it into our view of the world how we modeled it inside the domain layer we do not care how the database structures the data we do not care if the JSON response contains some additional fields or if the JSON response is sort of split into multiple parts which we need to even join together we do not care how the local database stores its data or how the location data is getting transferred from the device we do not care about any of that in the domain layer and it's the job of the data transfer object to contain the conversion logic for what we want to have in the domain layer and the data transfer object will also in turn contain the data as it should be present in the outside world because of course also when we want to send something as a request body to an API we need to fulfill the databases or the REST API expectations of how the data should be structured so it goes both ways conversion to raw data and also from raw data to entities and validate value objects happens inside these data transfer objects the last part of the infrastructure layer which we haven't talked about it are the repositories and these perform a very important task of being the boundary between the domain layer and also the application layer and the angry outside world because if you look at this diagram closely you whoops I just did something alright so if you look at this closely what you can see is that the data transfer objects go over to repositories also exceptions go over to repositories and then from the repository comes out either an entity or a failure so it's the job of the repository to catch all of the exceptions and return them in the usual flow of data as failures so the only place where you are going to see try and catch statements is gonna be inside repositories all of our error code up side will be free of any try-catch statements hopefully unless some exceptions happen in the widget layer but that's not really usual thing to worry about you usually do not catch any exceptions in the widget layer but should there be some exceptions in the widgets you are gonna catch them in here because as I said it in the beginning widgets are also at the boundary so yeah the boundaries basically handle any exceptions but when it comes to data coming from an API exceptions are all going to be handled inside the repositories and then of course these data transfer objects methods for being transformed into entities are gonna be all invoked inside the repositories so really ugly data will come in two repositories but repositories will return pristine and nice-looking data ready to be used throughout our app without any worries and also if you do not use firebase first or you are probably gonna need to cache data locally yourself because as you know firebase firestore does the data caching for you so if you use your own REST API the logic for deciding when to cash some data into your local database will happen inside repository this will hold the caching logic but again we are now gonna write that logic in this tutorial because we are using fire store and fire store does that decision for us of when to cash in what to cash now you know at least a bit more about the whole domain driven design thing about the separation of our app into four layers namely presentation application domain and infrastructure layers I know that this first part of this series was probably a bit too abstract to really get any actual idea of how we are going to build the app but this information which you have gathered in this first part is really crucial because without it we will not be able to progress forward at all because you need to have all of these basic concepts out and again I really recommend you to check out the written tutorial from the link in the description because over there you can go over all of this information even more in depth and at your own pace so that you can really absorb it to the full extent so really just go there and yeah because I cannot explain this information fully when I just talk about it because I surely forget about something so really go over the written tutorial and it's gonna be much better for you and also if you are serious about becoming a great far developer who can build real apps for clients or at the job go to flutter that education and link is also in the video description to get the top curated flower news and resources aimed at improving your app development career and over there you can also subscribe to my mailing list to get the best photo resources delivered weekly right into your inbox without you having to do a thing just receive the news and be informed about what's going on in the flutter world and also if you do not want to miss more tutorials like this and also of course the next part of this series which was so long time coming definitely subscribe to this channel and also join the notification squad by hitting the Bell button to make sure you grow your flower skills because here on reso coder I am just determined to provide you with the best tutorials and resources so that you will become an in-demand flutter developer if this video helps you to at least a bit understand the domain-driven design as it pertains to flatter give this video while I can also share it with our developers who are probably and Charlie and hopefully find it beneficial to leave a comment if you have anything to say and see you in the next video of this domain-driven design + firebase team water series [Music]

Channel: Reso Coder

Views: 88,211

Keywords: resocoder, tutorial, programming, code, programming tutorial, flutter, flutter tutorial, flutter firebase, flutter firestore, flutter firebase auth, flutter firestore tutorial, flutter firebase tutorial, flutter architecture, flutter architecture patterns, flutter domain driven design, flutter ddd, flutter database, flutter todo app, flutter todo app tutorial, flutter todo app firebase, flutter app tutorial, flutter app example, flutter clean architecture

Id: RMiN59x3uH0

Length: 34min 14sec (2054 seconds)

Published: Mon Mar 09 2020

Reddit Comments

[u/ackerlight]

This guy is good. Their videos are top notch.

However... he goes trying to implement everything like if it was the FizzBuzz Enterprise.

He implements whatever the Domain-Driven Design book says religiously. Just looking at how much he did to implement a simple text input that calls an API and display it:

https://www.youtube.com/watch?v=dc3B_mMrZ-Q

That is "too much overkill" for me. But if you wanna go that path, is ok I guess?

OT: On my search, I find out that these two other guys go straight to the point and also with great quality video content:

Paul Halliday

Code with Andrea