Let us set a little scenario for you. At hackajob HQ, we just got up from a meeting where someone explained a graph with the following statement, “where the lines go up, revenue goes up, and when they go down, revenue goes down”. Can there be a more basic, yet funny, explanation to something?
Before we begin discussing the importance of creating clean code architecture, we want to stress that we don’t believe that the concept of clean architecture actually means making your programme ‘clean’. However, the main advocacy that is argued for this approach revolves around a separation of concerns and ensuring that your code framework is agnostic.
As an example, imagine you’re working on a project using Django and then midway, your team decides to switch to Flask (for one reason or another). Would this mean rewriting every single line of code in order to match the new framework? If you search for ‘clean architecture’ online, the below image is one of the most popular results you’ll come across:
Take note of the arrows on the left side of the diagram. They represent the data flow in a system built using Clean Architecture. As an example, the ‘Entities’ only interact with the ‘Use Cases’ and not any other level, so let’s start with them:
As you can see, the ‘Entities’ interface is a pure Python-object representation of what the model below looks like. We recommend taking note of the ‘@abc.abstractproperty’ and ‘@abc.abstractmethod’ decorators in particular, as they are formal interfaces that we expect every ‘Employee’ object to have. Additionally, you should be able to see that the programme in this layer isn’t frame-work aware and can therefore be connected later to Flask with minimal changes to the overall codebase.
Remember that the ‘abstractmethod’ interface is present in the framework level as a custom model method. As shown in the ‘Clean Architecture’ image, the ‘Entities’ communicate with the ‘UseCases’. Based on the programme so far, the following would be an example of the interface found in the ‘UseCases’ level.
As of now, the interface only has one ‘find’ method, but you can add a ‘create’ using a similar approach. You can use this interface to create an employee like so:
In the code above, you can see that an employee instance is created. It’s key to note that at this point, there is still no mention of a framework and Python is the only language being used. The beauty of it? You can still hook this up with a Flask outer layer (or even something like Django).
Overall, Clean Architecture is one of the few topics that can cause a little contention in the office. Everyone is entitled to their opinion, and we believe that Clean Architecture makes code reusable when changing from one framework to another, which is a huge plus. Additionally, Clean Architecture creates separate layers for enterprise rules, application rules and other business logic. Although it can seem to be a little repetitive, it makes things much simpler once it’s set up. Hopefully, someone will come up with a boilerplate that we can all utilise by using a single command, and in the meantime... Happy coding!
Like what you’ve read? Be sure to check out our other technical articles.