Another fixation I think would be that the Main module is implementing which I think you meant referencing by the arrow from Main Module to it. I think the arrow should be closed head.
Hi! No, the diagram is correct. The delegate composite in the Main module implements the Use Case delegate to dispatch the calls to multiple instances. That's the Composite design pattern.
In the diagram Login Presenter has a reference to Login View Controller. I think it should be the other way around. As far as I've seen, VM or Presenter are always a property of a Controller.
Hi! There are many ways to implement it depending on the requirements. We discuss different solutions (including the Presenter depending on the VC or inverting the dependency, where the Presenter is decoupled from the VC - wait until around 22min to see it. Please watch the full video to see different design choices and their trade-offs. Thanks!
Hi, I see most of the architecture ralated diagrams are based on API related. Can you make a Demo architecture for image/video editing apps? Where API is less, but core functionalities are huge. Thanks for making great tutorials.
Hi! We have shared many videos not based on API related diagrams. For example, watch this series building an app without any APIs: www.essentialdeveloper.com/professional-ios-engineering-series
whoa. just found your tutorials yesterday and I’m actually binge-watching. You really know your stuff. You explain complex stuff really well. And this series is very informative. A colleague used the same architecture before and I understand it better after watching your videos. Thanks and keep it up! Just subscribed!
Hi Karla, thank you for your kind words and welcome to the channel! We're delighted to know you're enjoying and learning from our content. Have a nice day! ⛩
This is the best video I have ever seen for software architecture. I have been a developer for 3 years and is trying my best to be a Software Engineer by watching this channel.
Excellent tutorial I really enjoy rewatching it ^_^ I do have a question regarding the dependencies lines and the abstraction of the analytics module. Let's consider the example in which we need to add a dependency for a network manager. I would abstract it into a protocol and implement it, then inject it into the use case to use it, via the main module (usually I add one more specific layer, which is the gateway that talks with the network manager via the interface. Both gateways and network manager invert dependencies so there is not direct source code dependency from the higher level module, which is the use case, onto the low level details. In general the gateways are responsible, in the networking case, to create the requests. The gateways don't use low level details from the manager but rather they define some DTOs that are then used by the manager to create the request and send it. I do this in order to prevent the coupling from a framework like Alamofire or URLSession). So in this context, the business would hold a reference towards the low level details, a references that is inverted and the business don't depend upon it, but still can initiate the communication via the interface. In you example the dependencies are different for the analytics manager, in the sense that the business doesn't even know it exists. The question is when and why to use the analytics approach for the dependency vs the network manager approach that I suggested ? From my point of view the approach you presented should be used when the business doesn't need to directly initiate communication with that component but rather the component reacts to the events. Are there any other examples in which this should be used ? Is my network manager approach not correct ?
Thanks, Vlad! It depends if the functionality is part of the business logic or not. Usually, Analytics is a cross-cutting concern that's unrelated to business logic. Thus, it should ideally be implemented in a way that the business logic doesn't need to know about it. However, communicating with other systems/services is something that's usually related to your business logic. In this case, it's ok to represent those service requests in your domain services using DTOs as you described (but the concrete implementations making the network requests should be in the infra layer).
This was extremely helpful. I really like the way the Analytics logic get separated out to something "plugin" like. I am a bit confused on how you would actually implement this though. First of all we need to be able to add multiple delegates to the classes where we want to plugin our analytics, this can easily be done. But where would the logic that inits the Analytics (wrapper) and set it as a delegate for everything needed live?
So in this you created wrappers of different frameworks for login view controller, it looks good only for one module, what if when we are doing same thing for signup , feed and many more in that case if we need to get rid of crashlytics then we have to delete a lot of wrappers, which makes this task a bit difficult as compared to the earlier approach where we were deleted only one implementation of crashlytics
Hello! That's not a problem at all. A single wrapper can implement multiple abstractions from different modules to listen to events - so you don't need more than one per analytics framework. It's a choice 🙂 And even if you break it down into multiple wrappers, they all reside in the same module (and usually within the same folder structure), so it's easy to delete all of them at once if needed.
@@EssentialDeveloper Great thanks a lot , I was thinking same, I am going through all your videos and content one by one, thanks a lot for quality content and as you guys say I am on my way to become a better Senior Software Engineer . 🙏🏻🙏🏻 and I will be posting queries on your other videos as well 😅
Thanks for the video! At 5:35, you mention that the keys are created at a lower level compared to the engine which is at a higher level. Can you help understand how you determine high level and low level in this case. According to dependency inversion principles, High level module is the interface / abstraction that will be consumed directly by the presentation layer. Would that not make the analytics engines lower level compared to where keys are defined? Or are the protocol implementations considered to be "lower" level as their values are being "consumed" by the engines? Thanks in advance.
Hi Vijay! It depends on your design. Every component in your app lives between this High-level/Low-level spectrum, where some are more abstract (higher-level) and others more concrete (lower-level). In that first example, the keys were defined in the UI layer - which in that design is considered lower-level than the generic Analytics Engine (as the goal was to keep the engine implementations agnostic of concrete details). So if the engine implementations need to know about concrete keys defined in the UI layer, that would violate the desired dependency direction. But you can invert that dependency, as we show later on - where the UI doesn't define analytics keys anymore.
@@EssentialDeveloper Thanks for the response. I was thinking about the `generic Analytics Engine` as the low level module that will be called by the screens which are the high level module. Hence the confusion.
Hi Caio, Hope you are doing good. Great series in clean iOS Architecture. I'm having one query regarding the difference between architectures and design patterns. If MVC, MVVM etc., are called Design Patterns, then what do we call structural, behavioural and creational patterns. These comes under architectures or design patterns, please help me out.
Hi Pradeep, MVC, MVVM, MVP, etc., are architectural design patterns - but they're not app architectures. You'll learn more in the next episodes of this series. Enjoy 🙂
Hi there! Just trying to see if I got it right and would love your input. In the first video of this serie we had the issue where the AnalyticsEvent was passing metadata has a [String: String] dictionnary (hence cannot pass a Double or Integer if needed for some framework for example). So now in this video, the LoginAnalytics or also the AnalyticsWrappers would format the events into the SDK directly? So there would be no Engine and AnalyticsEvent anymore? In other words, those particular wrappers can be used only for the login, and depends on the concrete type of the analytics frameworks?
Hi! No, the idea is to decouple your components from specific analytics frameworks. Only the tiny composition wrappers/adapters talk to the frameworks.
@@EssentialDeveloper Cool! And the wrappers (in this case Crashlytics, Firebase and Custom) are used here for the login analytics. If you had another view, you would have different wrappers or the same one reused?
Very nice video. I have a question though. Who is responsible for binding all these things together? Is it the composeLoginUseCaseDelegate module that does it? I mean is it this module that creates LoginviewController, LoginPresenter, LoginUseCase, analytics wrappers and bind everything together, so every module/component gets it's dependencies from outside? Does it mean for every thing you need some kind of assembler that does these kind of things?
Hi! The main module is responsible for wiring up the types together. We believe this video will help you visualize better those ideas: th-cam.com/video/GzFD7R_CI04/w-d-xo.html
I think this is the best series that I have ever seen on TH-cam. I wish I know your channel sooner.
agreed! 😍 love it!
Another fixation I think would be that the Main module is implementing which I think you meant referencing by the arrow from Main Module to it. I think the arrow should be closed head.
Hi! No, the diagram is correct. The delegate composite in the Main module implements the Use Case delegate to dispatch the calls to multiple instances. That's the Composite design pattern.
In the diagram Login Presenter has a reference to Login View Controller. I think it should be the other way around. As far as I've seen, VM or Presenter are always a property of a Controller.
Hi! There are many ways to implement it depending on the requirements. We discuss different solutions (including the Presenter depending on the VC or inverting the dependency, where the Presenter is decoupled from the VC - wait until around 22min to see it. Please watch the full video to see different design choices and their trade-offs. Thanks!
Hi, I see most of the architecture ralated diagrams are based on API related. Can you make a Demo architecture for image/video editing apps? Where API is less, but core functionalities are huge. Thanks for making great tutorials.
Hi! We have shared many videos not based on API related diagrams. For example, watch this series building an app without any APIs: www.essentialdeveloper.com/professional-ios-engineering-series
whoa. just found your tutorials yesterday and I’m actually binge-watching. You really know your stuff. You explain complex stuff really well. And this series is very informative.
A colleague used the same architecture before and I understand it better after watching your videos.
Thanks and keep it up! Just subscribed!
Hi Karla, thank you for your kind words and welcome to the channel! We're delighted to know you're enjoying and learning from our content. Have a nice day! ⛩
This is the best video I have ever seen for software architecture. I have been a developer for 3 years and is trying my best to be a Software Engineer by watching this channel.
That 3 min talk up front changed my thoughts for how to code 👍🏾
You're the Bob Ross of programming ❤
The best explanation! Thank you 😎
I am blown away by how simple you made it
this is probably the best series so far
Stunning! This was such an eye-opener for me, thanks so much!
Glad it was helpful!
Thanks Caio!
Excellent tutorial I really enjoy rewatching it ^_^ I do have a question regarding the dependencies lines and the abstraction of the analytics module.
Let's consider the example in which we need to add a dependency for a network manager. I would abstract it into a protocol and implement it, then inject it into the use case to use it, via the main module (usually I add one more specific layer, which is the gateway that talks with the network manager via the interface. Both gateways and network manager invert dependencies so there is not direct source code dependency from the higher level module, which is the use case, onto the low level details. In general the gateways are responsible, in the networking case, to create the requests. The gateways don't use low level details from the manager but rather they define some DTOs that are then used by the manager to create the request and send it. I do this in order to prevent the coupling from a framework like Alamofire or URLSession). So in this context, the business would hold a reference towards the low level details, a references that is inverted and the business don't depend upon it, but still can initiate the communication via the interface.
In you example the dependencies are different for the analytics manager, in the sense that the business doesn't even know it exists. The question is when and why to use the analytics approach for the dependency vs the network manager approach that I suggested ? From my point of view the approach you presented should be used when the business doesn't need to directly initiate communication with that component but rather the component reacts to the events. Are there any other examples in which this should be used ? Is my network manager approach not correct ?
Thanks, Vlad! It depends if the functionality is part of the business logic or not. Usually, Analytics is a cross-cutting concern that's unrelated to business logic. Thus, it should ideally be implemented in a way that the business logic doesn't need to know about it. However, communicating with other systems/services is something that's usually related to your business logic. In this case, it's ok to represent those service requests in your domain services using DTOs as you described (but the concrete implementations making the network requests should be in the infra layer).
@@EssentialDeveloper Now it makes sense ^_^ Thank you very much for your response & clarification !
This is astonishing thank you!
excellent, wish I have known your channel earlier. Thank Caio.
Welcome to our channel!
It was pretty nice. Thanks
Glad you liked it!
This was extremely helpful. I really like the way the Analytics logic get separated out to something "plugin" like. I am a bit confused on how you would actually implement this though. First of all we need to be able to add multiple delegates to the classes where we want to plugin our analytics, this can easily be done. But where would the logic that inits the Analytics (wrapper) and set it as a delegate for everything needed live?
I should have seen part 3. before posting :)
That's it! You can see the implementation in part 3. Also, instantiation/composition lives in the Composition Root ✅
So in this you created wrappers of different frameworks for login view controller, it looks good only for one module, what if when we are doing same thing for signup , feed and many more in that case if we need to get rid of crashlytics then we have to delete a lot of wrappers, which makes this task a bit difficult as compared to the earlier approach where we were deleted only one implementation of crashlytics
Hello! That's not a problem at all. A single wrapper can implement multiple abstractions from different modules to listen to events - so you don't need more than one per analytics framework. It's a choice 🙂 And even if you break it down into multiple wrappers, they all reside in the same module (and usually within the same folder structure), so it's easy to delete all of them at once if needed.
@@EssentialDeveloper Great thanks a lot , I was thinking same, I am going through all your videos and content one by one, thanks a lot for quality content and as you guys say I am on my way to become a better Senior Software Engineer . 🙏🏻🙏🏻 and I will be posting queries on your other videos as well 😅
Thanks for the video!
At 5:35, you mention that the keys are created at a lower level compared to the engine which is at a higher level.
Can you help understand how you determine high level and low level in this case.
According to dependency inversion principles, High level module is the interface / abstraction that will be consumed directly by the presentation layer.
Would that not make the analytics engines lower level compared to where keys are defined?
Or are the protocol implementations considered to be "lower" level as their values are being "consumed" by the engines?
Thanks in advance.
Hi Vijay! It depends on your design. Every component in your app lives between this High-level/Low-level spectrum, where some are more abstract (higher-level) and others more concrete (lower-level).
In that first example, the keys were defined in the UI layer - which in that design is considered lower-level than the generic Analytics Engine (as the goal was to keep the engine implementations agnostic of concrete details). So if the engine implementations need to know about concrete keys defined in the UI layer, that would violate the desired dependency direction.
But you can invert that dependency, as we show later on - where the UI doesn't define analytics keys anymore.
@@EssentialDeveloper
Thanks for the response.
I was thinking about the `generic Analytics Engine` as the low level module that will be called by the screens which are the high level module. Hence the confusion.
Hi Caio, Hope you are doing good. Great series in clean iOS Architecture. I'm having one query regarding the difference between architectures and design patterns. If MVC, MVVM etc., are called Design Patterns, then what do we call structural, behavioural and creational patterns. These comes under architectures or design patterns, please help me out.
Hi Pradeep, MVC, MVVM, MVP, etc., are architectural design patterns - but they're not app architectures. You'll learn more in the next episodes of this series. Enjoy 🙂
20:00
I really enjoyed your talk. really really mean.
Hi there! Just trying to see if I got it right and would love your input.
In the first video of this serie we had the issue where the AnalyticsEvent was passing metadata has a [String: String] dictionnary (hence cannot pass a Double or Integer if needed for some framework for example). So now in this video, the LoginAnalytics or also the AnalyticsWrappers would format the events into the SDK directly? So there would be no Engine and AnalyticsEvent anymore? In other words, those particular wrappers can be used only for the login, and depends on the concrete type of the analytics frameworks?
Hi! No, the idea is to decouple your components from specific analytics frameworks. Only the tiny composition wrappers/adapters talk to the frameworks.
@@EssentialDeveloper Cool! And the wrappers (in this case Crashlytics, Firebase and Custom) are used here for the login analytics. If you had another view, you would have different wrappers or the same one reused?
It's a case by case decision. You can reuse if it makes sense for the case. Otherwise, create new ones!
Very nice video. I have a question though. Who is responsible for binding all these things together? Is it the composeLoginUseCaseDelegate module that does it? I mean is it this module that creates LoginviewController, LoginPresenter, LoginUseCase, analytics wrappers and bind everything together, so every module/component gets it's dependencies from outside? Does it mean for every thing you need some kind of assembler that does these kind of things?
Hi! The main module is responsible for wiring up the types together. We believe this video will help you visualize better those ideas: th-cam.com/video/GzFD7R_CI04/w-d-xo.html
what a good video!!!
Thanks!
What's this application that you use to draw dependency diagram?
Hi! It's draw.io
Oh got it. draw.io. Just ran down the comments.
is there any sample project abt this?
Hi Romin! Yes, we've built a whole series with those principles in practice: www.essentialdeveloper.com/professional-ios-engineering-season-1
Thank you so much. You guys are so awesome!
could you share your diagram, thank you
Hello! We don't have the diagrams anymore. As an exercise, you could recreate them on draw.io (it's free). ✅