 Give a big hand to Leonardo. Thank you. You can see my screen right now. Yes, yes. Okay, great. So, thank you. Welcome everybody. Today I will talk about the clean architecture in Python. The subtitle of the presentation is a tale of durability, utility, and beauty. And I hope it will be clear during the talk why I gave this subtitle. First of all, who am I? My name is Leonardo. I am a software developer and a blogger. I work in the cinema industry recently. I am into infrastructure working with AWS Terraform and all these fancy things. As I said, I'm also a blogger. I have a blog which is called the digital cat. And you can find it at the address there. I blog mostly about Python, but many other things. So yeah, come and pay a visit. I'm a cat person. And I like to see it just to say it because there is one specific thing I like about cats. They are very curious. And I like curiosity. I like to be into things, to dig into things and to understand how they work. So let's get into architecture. So what is architecture? This is the first question I have and I want to answer. You know, we can go around here in the picture. I have the cathedral of Lawrence. We can go around and say, oh, this is a beautiful building, right? Sorry, we don't see the cathedral. Maybe that's the, maybe that's your background. It's a space invaders. Oh, sorry. Sorry, I thought that that was your slide. Let me share it again. Can you see it now? Yes, yes, we can. Great. Sorry for this. So this is my blog. Okay, if you can see the cathedral now, you know, you can pass by and say, oh, this is an impressive architecture, right? This is an impressive building. It's very beautiful. But what do we mean when we say architecture? And so I dug into this and I found out that Vitrubius, who was a Roman architect, he was born around 70 BC. He was born 2,000 years ago. He wrote a book, which is called Dear Architecture, which means on architecture. And he says that every building should have three attributes, which are firmitas, utilitas and benustas. They can be translated in English into durability, utility, and beauty. Hence the subtitle of the talk. What Vitrubius says is that whatever we build should be durable, useful and beautiful. And there is another translation for durable, which is strong, but I prefer durable because it gives the idea of something that lasts, you know, that stands the test of time. I want to spend one second about this and think about your software. Think about what you create, how many times it is durable, useful and beautiful. Usually it's useful, I hope. Or, you know, like how long does, how much time does pass until your software becomes obsolete, for example. And beautiful, not to mention sometimes you look into your code and it's ugly. So I went a bit more into the definition of architecture. And the dictionary gives me this other definition. This is specifically for software architectures. And the dictionary says the art and science in which the components of a computer system are organized and integrated. So I'm going to start here because it's art and science. So I now think about it, art and science. So how many of you consider themselves artists and scientists. You know, we call them ourselves coders, usually, you know, engineers, art and science, which means that what we do when we write that code is art. And we have to treat it as that. And here's another thing that I want to mention about this definition. It says organized and integrated. So organization is about where things are in your system. So when you create a software, where are the components, not only where they are physically speaking, but where are they in the system, in the diagram and chart. They're integrated. So how does data flow between the components when you use the system. Okay, and now that I maybe define architecture, let me discuss if we need it. And many people believe I chose this picture because maybe that the house here is not an impressive building. In the country, I chose it because I was struck by this when I saw the picture for something completely different when I saw the picture I thought whoever built these didn't have the best, you know, the best materials, or maybe the best science because you know this is a bit leaning is not, it's not perfect. I wanted this building to be beautiful to last they have a roof, they have a door, you know, so it's poor, maybe, but it's beautiful. And this is what I want to say about the main thing I want to say about architecture, we need architecture because we want the things we do to be beautiful, we need it. So it's good for us to study and to discuss architecture because in the end what we do can be beautiful can be durable. And the other thing I want to mention, this is more bit more technical is that if you don't decide for an architecture if you if you don't commit to an architecture if you don't think about it. Then someone else will think for you will decide for you. And usually this is the framework that you use. So I know for sure that you know in the Python world, many people use jungle or flask, for example, they are impressive frameworks I like them a lot I'm not here to say they are not good. But think about this when you use one of those frameworks, you are automatically committing yourself to the architecture they push one example in Django and flask as well. Models are connected with the database. And usually the database is a relational database. And these are architecture choices, and you commit to them automatically because you committed the framework. So this is what I mean, you have to think about the architecture you have to care about. And people have been discussing architectures since the very beginning. So I just listed here some of the books that I read in my career. They are very useful they're very interesting. They are word of caution. So these books are not, you know, like readings for when when you lie on the beach under the sun, that you have to study these books. So if you don't want to commit to these doorstoppers because they are very thick sometimes. I highly suggest that you read at least the introduction to the two books I marked in reference to child design patterns and enterprise integration patterns. Both introductions are very fluent. They are not too technical, but they give you a great example of architectural discussion. How do you think about your requirements, how you design a system. So if you have the chance, read at least that if you don't want to read the whole, the whole book. So now I defined and discuss a bit architecture. Let's discuss the other word clean. So cleanness, what is cleanness. I can easily show you something which is not clean. Here we go. So I strongly believed a few just a few people are probably nobody who wants to work in such an environment. Because I would be scared every time you know you have to pull a cable. How do you know which one is the right one, you know, in an emergency. This is hell. So this is definitely not clean. What is clean. This is clean. What is the meaning so of clean is that in such a system looking at this cabinet, I can say where things are I can easily see the path of the cables. I know why the components are there I know what something is you know that they are like labels for example. And it's easy. It should be easier to work with with such a such a system. So the clean architecture is a way to structure your software in order to be like this, in order to be something that you can easily manipulate this can easily work in easily change work with. Unfortunately, I have unfortunately not much time I can only scratch the surface of these concepts. Lucky for you know I don't know if you are interested I wrote a book to two years ago which is called clean architectures in Python is freely available. If you want to donate and not going to complain. And I discuss the example I'm going to show you today in gray details in all the details so probably too many too much. So today I'm going to scratch it if you're interested go and fetch the book and read the whole example. The only example I'm going through is that of web service, which a single and we with a single endpoint, which is slash items, and the purpose of the website, the web service is to show a list of items fetched from a data source. This is really trivial is really, really, really trivial. But as I said, it's architecturally interesting. It's not about the technology. So, yeah, this is the clean architecture. This is the standard depiction of the clean architecture as Robert Martin. Robert Martin gave these ideas, the name clean architecture, but these ideas have been around since the very beginning. They are as old as computer science. This is important because I'm not here to advertise over Martin I don't agree with him on everything, for example. But this is what he calls the clean architecture. There are four layers called entities, use cases, gateways and external systems. These are the standard names. And the important thing I want to mention is that the architecture is secure. So the layers are secure. What are these layers? These are virtual layers. So they are the areas which your components belong to. So when you create something a class, for example, it belongs to a certain layer. And there is an important rule in the clean architecture, which is that whatever is in a layer, like for example here in use cases, cannot see what is outside. For example, you create a class in Python, we are talking about Python, so you create a class in use cases, you can instantiate everything that is created in the entities layer. But you can't instantiate and you can't see what is created outside. And these are just rules that there is nothing, there is no library, no IDE, nothing in the language that enforces this. It's just the rule that you give yourself following the clean architecture. So the golden rule, I'm going to show you an example in a minute, but the golden rule is that you talk inward with simple structures and outward with interfaces, as I said, an example in a second. So let's dive into the proper example. Let's start with entities. These are the models of my domain. So in this case, as I said, I want to list items, generic items. So as you see here, I have a class which is called item and has two attributes code and price. I'm going into the code and price now. There are just two attributes. One important thing. These models are very simple. If you are used to Django or Flask, you can see, or I'm telling you, these models are not connected with the database. They are just containers of data, they can have methods, but they are not connected with the database. So these are very, very simple models. Then we have the use cases. And let me spend some minutes about use cases. What are use cases so they are what contain your business logic business logic is the most important thing in a system. When the business logic is the reason why you create your software or why you create your startup and, you know, and you go and you provide some software to the world, because this, the business logic is what you are able to do. Let me give you an example. Everybody can index websites, right? It's very simple. But only Google can do it that way. We can discuss if that is a good or bad way. I'm not here to advocate Google. But arguably, that is what makes Google different from something else. And that is the business logic, the way they index websites and the way they are able to index websites and run them and whatever. So that is the business logic. In this case, given it's a very simple example, we have an impressive algorithm to list items. Yeah, sorry. That's it. Use cases in this example are simple classes, they can be executed and basically that's it. You can just run your business logic as a sort of a recipe. We want to build a web application, as we said. So I create, I created in task, our root items. And I connect the root with my use case. Here you can see what I mentioned about the code and rule. So the web framework has one single task, which is to receive HTTP requests, and to convert them into something that the use case can digest. In this case, like for example dictionary, this is a simple structure, because the use case can't can't see anything that is outside here. So it gets a simple structure. I'm passing here like request. It's just an example. Then you want to your repository because you want to store data somewhere, right? But a word of caution. This here I mentioned it as a database, but this should be repository because I didn't say it's a database. I didn't say it's a relational database. It's just a way to store data somewhere. It might be REST API. And we need some way to access that interface. This is another important thing. There is, all these systems are the couple. There is social distancing, right? Everything components. If I am in the use case class, and I call directly, like for example, let's say this database is Postgres, and I use PsychoPG. It's a Python library to talk with Postgres. And I embed PsychoPG calls into my use case. And suddenly my use case is coupled with the database. If I want to change the database, if I want to use something different, I can't. I have to change my business logic. This is bad. So my business logic should be mutable, or at least not depending on the way I store data. So I create an interface that translates the connection with the database. So here I have the interface, repo, and I pass the interface to the use case. So that the use case can be aware, can use it. But as I said, it's an interface. This is a complex matter, maybe, but the idea is that I'm not instantiating directly this in Python, but I'm using it as an object. I'm just using its methods. As I said, the database interface gets simple structures like a dictionary. It translates these into the specific language, like for example the language that Postgres uses, or you see here I'm using SQL Alchemy, because in this example this is a SQL database. If it was MongoDB, you should use something different. Database answers with the specific language and the database interface responds, sends back data to the use case. So the use case communicates with simple structures and gets simple structures. Entities are considered simple structures because they are, you see, everybody can see them. They are in the center of the dialogue. And finally, the use case returns the data, whatever comes out of the business logic to the web framework. There is business logic here. So in this example, the business logic is almost nothing because we are just listing items. But for example, let's say we have an impressive algorithm to rank items according to the price. So we return the result of the business logic to the web framework. And the web framework has another task, so to be honest, the web framework has two tasks. One is to translate HTTP requests, and the other one is to translate the result of the business logic into HTTP responses. Like there is an example here. So this is the trivial example about the clean architecture. And as you can see, what I did is not evolutionary. I just decoupled the systems. I have a web framework, which is decoupled from the business logic. Think about Django views. Django views contain the business logic, but they are part of the framework. Instead, I decoupled the database interface and the database and any other system that we can have here. Okay, one of the main advantages of the clean architecture is that it's testable. So since components are decoupled, I can take them out of the whole system and test them in isolation. So this is extreme input. As for the use case, which is the business logic, it's the most important thing we have to test. So we can basically look at it and think, okay, we have some input here that comes from the web framework. We can fake it. It's just dictionary. We can fake the database interface because again, we are just passing some data here. And these returns entities, we can have a fake object that returns entities. We don't need the database. And again, we can, we are returning something from the use case, and we can check that is correct. We don't need to check the HTTP response because this is not what the use case does. So this is easily testable. This is unique testing because extremely fast. And then we have what are usually called integration testing. So the web framework is an external system. I need to find out and to have something that sends HTTP requests and checks HTTP responses. And then we have the database. Again, this is an integration test because I need the database engine running to test it. But I'm not testing the database and testing the database interface, you know, like Postgres is tested by the people who wrote Postgres. I don't need to test it. Cool. So let me address a couple of questions and then I'm going to wrap up. Is it possible to migrate an existing system? It's possible. I advise you to do it bit by bit. If we are talking about a web framework, use load balancers or, you know, proxies to root some of the, some of the requests, some of the URLs into your new system, don't replace the whole system in one go because it doesn't work. Another thing is more important is this definitive architecture. And I think there is no such a thing to strongly depends on the requirements. So what are your requirements? The clean architecture lasts forever is a very good example is a very good architecture, but it depends on what you are trying to achieve. So don't throw your framework out of the window. After this talk, you're probably not going to do it and yeah, think about requirements. As I said, there is a book I wrote, Go and Fetch It. There is another book written by a friend of mine, Hi Percival, he is very known in the Python community. The book is Enterprise Architectures Patterns with Python, published by Aureli, and it's freely available on that address because already gently kindly agreed on publishing it open source. And I think that's it. I have five minutes for questions. I hope it was interesting enough for you. Thank you very much, Leonardo. Yes, we do have a question from Matthew. I see the word design comes up a lot for the books you recommend. Do you differentiate between design and architecture? If so, how? Oh, interesting. Yes, well, long story short, I think architecture is, I associate architecture more with the technical side of the things. So how do we implement things? I didn't differentiate that much in this talk. Design is more about where components are and what they are, what's the data flow, you know. Technically speaking, architecture is for me, more about how to implement this specific thing. But yeah, we might have another talk maybe about this. I don't know. It's a very long answer maybe. Awesome. That's it, no more questions. Okay. Thank you very much. Get in touch if we have a channel on Discord or Twitter, whatever, if you want to go on discussing these things. Yeah, awesome. Thanks, Leonardo. Thank you very much.