Does Clean Architecture Actually Help in Mobile Development?
I'd heard of Clean Architecture years ago, but after finally reading the book, I’m reflecting on how deeply it moved (?) me...
Defer decisions as long as possible.
This phrase has been stuck in my head ever since I finished the book 🤗
Before reading the book, whenever I developed a service, I’d think, "I need these features, so I'll structure it like this and set up the DB schema like that!" and just dive right in. (Whenever I was setting up the architecture, I would always decide on everything—even the parts that didn't need early decisions—before starting development.)
So, what happened after reading it?
It brought about many changes, but if I had to pick the two biggest ones:
Why does development efficiency drop or stagnate at some point, even though we keep hiring more engineers?
(Honestly, this isn't strictly related to the book, but maybe because I read it with some experience under my belt, this thought crossed my mind a lot.)Let's think about the service policy first, and defer decisions as much as possible for anything that doesn't impact that policy!
Things unrelated to the service policy:
For example, which DB should we use?
Where should we store the data?
By deferring these decisions, removing dependencies between them and the core policy, and then starting development, you can design an architecture where changes become easier whenever the service policy needs updating.
To grow a service, startups run many experiments, which naturally requires tons of modifications along the way. I believe applying Clean Architecture helps tremendously with this. (To maintain a highly adaptable structure, DelightRoom is applying Clean Architecture to the Alarmy project!)
Clean Architecture?
I think Clean Architecture is a development methodology built on Uncle Bob's wealth of development experience.
(This image is one we’ve all seen countless times in the book and on the internet..!)
I believe Uncle Bob said that dependencies must point inward, and the closer you get to the center of the circle, the closer you are to the service policies and the greater the impact of changes.
Based on the diagram above, the Clean Architecture structure in mobile development can be drawn like this:
Presentation (UI layer)
Domain
Data (DB, etc.)
It can be broadly divided into these three layers, and both the Presentation and Data layers (everything except Domain) will have dependencies pointing toward the Domain layer.
Domain
The most important things in the Domain layer are the core business rules and the application business rules.
Entity — Provides the core business rules for the service domain
Usecase — Specifies how and when to invoke those core business rules
For example, in Alarmy, an Entity can be defined as an alarm. The user can use the alarm Entity for functionalities like ringing the alarm and dismissing it. Specifying how and when to call these core business rules inside the Entity is the job of the Usecase.
To list Alarmy's Usecases:
The user can start a mission when the alarm rings.
The alarm is dismissed when the user completes the mission.
We could define things like this.
Presentation
The Presentation layer handles the UI, and if we recall the earlier phrase, "Defer decisions as long as possible," it's a layer you can figure out after designing the Domain layer.
(Changes in this layer will never affect the Domain layer. That's because the direction of dependency flows from Presentation to Domain.)
In the Presentation layer, various application architectures like MVC, MVVM, etc., are applied as defined within the circle, and it's where you decide how to draw the UI using tools like UIKit, SwiftUI, and so on.
In mobile development, the UI changes frequently due to experiments or various other reasons, but since work in the Presentation layer doesn't impact the Domain, a huge advantage is that you can make changes comfortably.
Data
The Data layer is the layer that processes data. It handles the roles of saving and loading data. Similarly, changes made here do not affect the Domain layer.
This layer is where you define which DB to use, like Realm or CoreData, or if you're communicating with a server, which server to use.
An important part of the Data layer is that its relationship with the Domain (service policy) must be clear.
(Separating the Entity and the DB Model) This is because the Domain layer doesn't care where or how specific data is stored. (It just needs the business rules to run properly.)
When doing mobile development, swapping out a DB shouldn't happen often, but... it happened more than I thought.
Realm -> CoreData, or CoreData -> Realm, Local -> Server, etc...
Just like Presentation, changes in the Data layer don't impact the Domain layer, giving us the nice advantage of only needing to worry about the Data layer itself :)
To sum up... how does it help in mobile development?
In mobile development, you can broadly decide on three components.
Decide the service policy first.
Decide how to display the UI (screens) for that service policy.
Decide how to handle data management.
By deferring decisions, you can establish boundaries between components, and use them as a foundation to increase the flexibility of a mobile service.
In other words, you can respond swiftly and adapt flexibly to the parts requiring changes in each layer, ultimately delivering a better experience to the user faster and more safely!
The above are my subjective thoughts that came to mind while maintaining apps built with Clean Architecture after reading the book!
I'd appreciate diverse feedback and interest rather than 🔥criticism🔥 (_ _) 🤗
Check out our Instagram for a sneak peek into DelightRoom's daily life