Common Clean Architecture Patterns
In iOS and Android development specifically, there are a number of different patterns developers you can use that follow clean software architecture principles. A couple that I like to use include:
This pattern encapsulates some of the logic that you’d usually have within a View Controller by separating the GUI (or the View) from the business logic (or the Model) underneath. The ViewModel, meanwhile, manages the interactions between the GUI and the business logic.
For iOS development, in particular, you can also work in flow coordinators within this pattern. Usually, to transition between views in a model application, you’d end up writing repetitive code and add it to your logic flow. The flow coordinator, however, automates that process while also separating this concern so it can be modified independently.
View, Interactor, Presenter, Entity, Router (VIPER)
One of my favorite clean patterns, VIPER, is more granular than MVVM and is widely used when an application’s requirements are already well-formed.
Similar to the general clean architecture layers, each letter in VIPER stands for a different layer with a different purpose:
View: Displays information from the Presenter and sends input from the user back to the Presenter
Interactor: Business logic layer, dependent on the Use Case rules (see above)
Presenter: Sends information to the View layer and reacts to user inputs sent from the View layer
Entity: Contains model objects that the Interactor uses
Router: In charge of navigation, or which screens are shown to the user in which order
VIPER takes away much of the repetitive code and redundancies you’d encounter outside of a clean pattern so that everything is organized and operates more efficiently.
How Can You Transition to Clean Architecture?
If you’re starting a mobile development project from scratch, implementing clean architecture is simply a matter of selecting the right patterns, tools, languages, and teammates to build something that follows clean guidelines. Hand-me-down projects, however, can present more challenges. How do you transition to clean architecture when you’re starting with something really messy?
The short answer is that you implement clean architecture the same way you eat an elephant — one bite (or step) at a time.
While it might be tempting — especially in moments of frustration — to do a complete refactor when you’re dealing with messy code and architecture, business realities usually don’t allow for those kinds of changes. Starting from the ground up would likely be a months-long project that most clients, whether internal or external, wouldn’t be too happy about (and understandably so).
Instead, you’ll have to go slowly. While it may seem at first like untangling a complex knot, the end result will be more efficient code and architecture throughout the application, which means better future efficiency and resiliency as the app changes hands.
If your project is ongoing or needs a new feature added, this is a great opportunity to start implementing a clean architecture. You can create a subdirectory just for the new section or feature that you’re working on, and start to separate everything into layers based on the pattern you’ve chosen.
Before you know it, you’ll have one module that’s very nicely architected and written. As you move on to older, messier sections, you can apply the pattern from the new module to gradually transition to something cleaner.
This approach isn’t without its challenges, however. Sometimes, you’ll encounter features for which software developers have previously written tests. When you try to refactor the feature, the test breaks because it’s dependent on the original code. In these situations, you may have to adjust your plan to get the best result, as adapting the tests themselves can prove even more complex and time-consuming.
Transitioning to clean architecture will be a gradual process, and the plan you follow will depend on your organization’s own goals and priorities. Do what you can, and try not to break anything. Ultimately, the work you do will likely be an upgrade to what was there before and will set up your product for success.