Clean Architecture: The Secret to Cutting Costs and Scaling Smart
When building an app, there are so many unknowable things to consider that you wonder how anyone does it without a crystal ball. Especially now, in the Age of the Pivot.
Selecting and sizing your database is a perfect example. If you fail to guess right, you’ll bear the costs of overage, outages, higher operational costs, and on and on. How much traffic do you expect? What features will you add in the future? What systems will you need to integrate your database with?
I don’t know! I just have a cool idea!
I hear you! I’ve been where you’re at.
Even if you have an expectation or vision for all of that, at the end of the day, you can’t predict the future. The architecture of your app can help you prepare for the unknown without having to predict it.
Traditional monolithic architectures can* have disorganized architectures that waste a lot of motion (and therefore money). For example, these apps often use a single database layer, meaning one query must be run several times for different components. Each of these transactions costs. Plus, the unnecessary traffic taxes your database’s resources, like memory, disk space, and bandwidth, so your app’s performance suffers.
It’s like making an individual trip to the grocery store for each ingredient you need for a recipe.
On the other hand, clean architecture simplifies an app’s functions by structuring the components into layers based on their dependence on one another. By doing so, the app doesn’t waste resources, and it’s simpler to scale and evolve.
That means you can adapt to whichever way the wind is blowing when that time comes.
Conscious Coupling: A Primer on Clean Architecture
We’ve all suffered under an overly-complicated company org chart or an obligation to a project that has nothing to do with us. It detracts from our ability to do the thing we are supposed to be doing.
An app is the same way. Monolithic apps can be plagued by unnecessary dependencies (we call this “tight coupling”). Essentially, everything is dependent on everything else. In addition to creating a complicated (aka more expensive) route for database queries, tight coupling makes code changes more difficult, because you must account for the ripple effect of dependencies.
The questions become:
What dependencies between departments are necessary?
How do we simplify that coordination?
Which dependencies are unnecessary, and how do we eliminate them?
Enter Clean Architecture
Clean architecture organizes the different components of an app into layers based on their technical dependencies. The clean architecture model is often portrayed as an onion.
The domain layer is the core of your app. It contains the business logic for what your app does, along with the rules for interacting with the data store.
The application layer acts as a middleman between the domain layer and the surface of the app, which the users interact with. It handles things like redirecting requests and preparing data from the domain layer.
The infrastructure layer serves as the connective tissue between the app and the external systems and services it relies on, e.g. database and web servers, external API wrappers, and communication protocols.
The UI layer is the outermost layer, which is where users interface with the app.
In this model, all dependencies point inward. The UI layer may depend on the application layer, but the application layer doesn’t depend on the UI layer, for example. The domain layer depends on nothing.
Returning to our business analogy, the CFO doesn’t need to have a hand in ordering more paperclips, but the office manager ordering the paperclips does depend on the CFO’s decisions around the budget the manager has at his or her disposal.
The end result is an app where each layer of components can focus all of its resources only on the tasks it was designed to handle.
Cleaner is Simpler is Better.
Dealing with messy code is like living in a messy house. It’s a bummer. It’s hard to live in, let alone make improvements to. Clean architecture is just that: Clean.
Lighter-weight code performs better and faster.
Fewer dependencies make for easier updates.
Testing, debugging, and refactoring are easier because there are no unnecessary changes to make and components are more reusable.
Operational costs are lower thanks to fewer database queries, the lower likelihood of downtime, less expensive testing and updating, etc.
Even if you don’t plan to make any user-facing changes to your app, it will require updates to keep it functional, and you’ll want to consider costs beyond the sticker price. If you’ve got clean code and smart architecture, the amount and price of necessary updates will be minimized, and that will give you the bandwidth to make changes and add new features based on fresh inspiration alone.
How Do You Ask For Clean Architecture?
This is a tough one because any potential app development partner will say, “Of course our code is clean!”
But you can’t just trust them at their word. You’ll have to do a little digging. Ask them to run you through a demo of products they’ve created, and you can also ask to speak to those clients.
Personally, as a business owner, it can feel burdensome to ask my clients to talk to prospects multiple times a month. Instead, I had a third party, Clutch, interview them the same way a prospect would and create an independent write-up. This saves both parties time. You could ask your potential partner if they have anything similar.
If you do talk to previous clients, here are a few red flags to look out for that are specific to vetting code quality:
When the developer makes a fix, does it create more, unrelated problems? This may indicate messy, unstable code that will make the app a pain to iterate.
When the developer handed the project off, did it work? Sure, you may want to make some superficial changes, but the app should perform all functions as expected with minimal errors.
Is the relationship ongoing? It’s always a plus when a developer has iterated on the same project over a long period of time, and a double-plus if the client has enjoyed working with them.
Has the developer worked on projects with the same level of complexity as yours? The bigger the project and ambitions for the product, the higher the stakes are around architecture and code quality. That said, even the simplest app can become a dumpster fire due to low code quality.
Your app is your brainchild, a product of your creativity. You shouldn’t dread the process (and price!) of evolving it. Clean architecture saves that headache, so you can remain excited and energized for the long term.
*The right architecture has a clear structure, and sometimes a monolithic app makes sense. Managing a monolithic architecture can require less effort and reduce complexity; when something goes wrong, troubleshooting is simpler as everything is in one place. If built well, monolithic architectures can deliver strong performance with efficient communication and resource sharing between different parts of the system. The decision you make depends on various factors: the number of users, the stage of the product (market research, MVP, or mature product), the development timeline, and the budget. You will want to analyze requirements, calculate potential growth and resources, and - as always - use best practices to build the product in a fast and efficient way.