You get the streams of changes and Events from UI there and decide what’s the next state should be and yield it. Learn more from the mysterious uncle.”Īs far as I know, it’s recommended to have one BLoC class for each page. I’d recommend creating reusable, one-purpose UseCase classes. “If you’re not using BLoC, do yourself a favor, and don’t put the application logic into View Models. My concern is about Application layer for those who use BLoC and those who use for instance ChangeNotifier + Provider with MVVM pattern. Notice that splash folder in the presentation layer? There is no inherent "splash screen logic", so it doesn't make sense to put it into other layers.Īll in all, we can mix and match the dependencies in between features as long as we keep true to the dependency flow outlined in the diagram above ( domain layer has to have ZERO dependencies on other layers). It's also worth noting that some features don't even have to necessarily be represented in all layers. What does this mean? Well, we can have both a good folder structure and a separation into architectural layers at the same time 🎉🥳 While the main notes folder is present inside every layer (application, domain, infrastructure, presentation), its subfolders are different!
#DOMAIN DRIVEN DESIGN CODE#
This will still keep the code readable but, most importantly, it will ensure that adding more features and sub-features is going to be a pure bliss! Layers will hold features, not the other way around. With DDD, we're going to take a different approach.
I'm the first to admit that the folder structure outlined in the Clean Architecture course is a pain to deal with.
0 kommentar(er)
