Many people tend to talk about architecture as layers. It makes sense to some extent. You develop one layer, and the layer immediately above knows and can communicate with the layer below.
If we develop iOS apps following this principle, we could probably develop the models, repositories, viewModels and controllers, as separate layers, each layer communicating with the layers below, and we could create a folder/group for each of these layers, and put every component of that layer in that folder. Following this principle, we'll end with a group full of models, another group full of repositories, and so on.
Well, from my viewpoint, this is not the ideal, and I'll explain you why.
What are our goals when designing an architecture? I can say that in my opinion, the goal is reducing the developer cognitive load while isolating modules as much as possible. I tend to think apps as modules. A module is a cohesive unit that contains all the layers that belong to a single concern. In the architecture cake, a module is a piece of the cake.
Architecture is not an onion, it's a cake. Unlike an onion, you serve a cake in pieces, each piece of the architecture cake is a module you can eat without involving the rest of the cake.
If you have a Twitter client, you might have a Tweet creation screen, where every class related to the Tweet creation will belong to the same folder/group. When you are working on the Tweet creation, you know that everything related will be in the same place.
Another benefit that comes with this approach is that it will be easier to split your app in different modules and then integrate all of them using a package manager like SPM or Cocoapods.
Top comments (0)