Clean Architecture a Marketer Can Understand in 10 Minutes
Why an Alarmy engineer strives for clean architecture
1
There’s an ad we recently produced at DelightRoom that’s been performing really well.
It’s an ad highlighting the ringtone feature in the Alarmy app. Thanks to this ad, I was reminded of the importance of clean architecture, which I learned the hard way while developing that very feature. I even got to share this realization during our recent town hall meeting.
Alarmy offers various ways to customize alarm sounds to satisfy our users' diverse needs. The ringtone feature in Alarmy includes several different types of ringtones, as shown below:
- 서버로부터 벨소리를 다운받아 사용하는 알라미 벨소리
- 여러 인플루언서 분들과 협업하여 만들어진 인플루언서 벨소리
- 직접 유저가 녹음하여 사용하는 녹음 벨소리
- 기기에 저장된 음원을 불러올 수 있는 기기 벨소리
I recently added the influencer ringtone feature to the Android Alarmy app, and through that process, I finally understood and applied clean architecture. I'd like to share what I learned using an analogy.
Understanding clean architecture through an analogy
To easily wrap your head around clean architecture, let’s compare Alarmy’s ringtone feature to a factory. Imagine a factory that produces a product according to a recipe, stores it in a warehouse, packages it, and then delivers it to the customer.
If we map each of these components to the actual ringtone feature in Alarmy, it looks like the diagram below. Alarmy downloads ringtone files from the server, saves them to the local DB, and presents them to the user through the UI.
(What is a Use Case? - The way a system or service operates so a user can utilize a specific feature.)
What if you were the factory manager?
Now, if you were the manager of this factory and had to write the product manufacturing recipe, which of the two recipes below would be more efficient?
The difference between the two approaches lies in the bold text. You can see that Recipe B gives much more specific instructions.
Have you made your pick?
According to clean architecture, the correct answer is A.
Why is A the better choice?
The reason is that the factory, warehouse, and packaging can change at any time. You might switch from a warehouse in Gyeonggi to one right in Seoul, or revamp the packaging from paper bags to boxes.
This potential for change applies just as much to feature development as it does to a physical factory. It’s exactly like how we recently changed server locations and ringtone storage paths when adding the influencer ringtone feature in Alarmy.
In other words, Recipe A allows you to adapt to changes even if the factory, warehouse, or packaging swap out. Recipe A can produce ringtones in both the standard Alarmy ringtone factory and the influencer ringtone factory, whereas Recipe B can strictly only produce them in the standard Alarmy ringtone factory.
The important takeaway here is that the use case and the ringtone product itself do not change as often as the other components. The fact that Alarmy provides a ringtone feature is a core concept that won’t frequently change over time.
Bringing it back to clean architecture
If we separate the components we just looked at into those that change frequently and those that rarely change, it looks like this:
The core of clean architecture is drawing a boundary to isolate things that change frequently from things that don't. This is the way to build a structure that remains flexible to change.
By this point in the story, I hope you agree that it’s crucial to properly isolate the frequently changing parts. To do that separation well, it’s a great idea to apply clean architecture to your development process!
However, when you first try applying clean architecture, you might run into a dilemma: it’s hard to predict exactly which parts will change and which won’t. When the ringtone feature was first born in Alarmy, could anyone have accurately foreseen what would or wouldn't change? Whenever you face this concern, it helps to refer back to the famous clean architecture diagram.
To understand the diagram simply: components closer to the outer edge are those that change frequently, while those closer to the center of the circle are the ones that rarely change.
For clarity, if we map the components from our factory analogy onto the diagram, it looks like the following:
You can see that the things that changed and stayed the same during the development of the influencer ringtone align perfectly with the diagram. It’s up to the engineer to carefully define the boundaries of these components based on the team’s situation, business requirements, and other conditions, and then connect them loosely using methods like DI (Dependency Injection).
Why this ringtone development experience was so special
In the Android Alarmy project, the legacy ringtone feature had been developed a long time ago and was not built with clean architecture in mind. At the time, I wasn't entirely convinced about clean architecture myself, so I initially went in a different direction when refactoring the code structure. When developing the influencer ringtone, it took a huge amount of time to extract and decouple the hardcoded logic (like the bold text in Recipe B). As a result, even though the influencer ringtone only required changing the server address and the file storage location from the existing feature, it took about a month of development time.
In stark contrast, the iOS team, whose code was already built on clean architecture, was able to add the influencer ringtone in just a few hours. That’s why, more than any other feature, developing the ringtone taught me the immense importance of clean architecture. It was a difficult task, but I learned so much that it remains a deeply appreciated experience. The Alarmy Android team is currently improving our features based on clean architecture. Through this, we aim to build a structure that can rapidly respond to changing business requirements and deliver even more value.