Clean Architectures in Python - presented by Leonardo Giordani

Summary

In this insightful talk, the speaker explores the concept of 'Clean Architecture' in Python, emphasizing the principles of durability, utility, and beauty in system design. Drawing from Vitruvius and modern interpretations, the presentation delves into the layered approach of software structuring, advocating for clear separation of concerns to enhance testability and customization. The speaker contrasts this with the 'Jungle Architecture' of Django, highlighting the trade-offs between out-of-the-box solutions and customizable systems. The talk concludes with practical advice on adopting clean architecture incrementally and the speaker's personal reflections on the beauty of well-organized code.

Takeaways

• 📚 The speaker emphasizes the importance of considering code as an architecture, needing to be durable, useful, and beautiful, drawing parallels with the classical architectural principles of Vitruvius.
• 🤔 The talk provokes thought on how often developers consider the longevity and aesthetics of their code, alongside its utility, challenging the audience to view coding through a broader architectural lens.
• 🏗️ Clean architecture is introduced as a concept by Robert C. Martin, promoting a layered approach to software design that enhances maintainability and testability, with a focus on business logic at the core.
• 🔄 The principle of clean architecture involves a unidirectional dependency rule, where inner layers define simple structures and outer layers implement interfaces, to prevent tangled dependencies.
• 🛠️ The speaker illustrates the clean architecture with a Python example, demonstrating the separation of concerns between the use cases, entities, and external systems like databases or web frameworks.
• 🔍 The benefits of clean architecture include improved testability due to the isolation of components, allowing for unit testing of business logic without reliance on external systems.
• 🛑 The speaker advises against a complete rewrite to adopt clean architecture, recommending incremental changes and leveraging existing infrastructure to avoid the risks associated with full-scale overhauls.
• 📈 The potential for customization and flexibility in clean architecture is highlighted, as it allows for different storage solutions and front-end presentations without affecting the core business logic.
• 🤝 The talk concludes with a comparison between clean architecture and other architectures like Django's, suggesting that the choice of architecture should be informed by specific project requirements rather than a one-size-fits-all approach.
• 🎨 The concept of beauty in code is discussed as a personal and subjective experience, related to the elegance and harmony of how components interact within the architecture.
• 📚 The speaker mentions offering a free book on clean architecture, indicating a resource for those interested in learning more about the principles and their application in Python.

Q & A

What is the main theme of the talk titled 'Clean Architectures in Python: A Tale of Durability, Utility, and Beauty'?

The main theme of the talk is to explore the concept of clean architecture in Python, emphasizing the importance of creating systems that are durable, useful, and beautiful, inspired by the principles of the Roman architect Vitruvius.

What are the three key attributes of architecture as defined by Vitruvius?

Vitruvius defined the three key attributes of architecture as firmitas (durability), utilitas (utility), and venustas (beauty).

Why is the concept of 'engineer' relevant to the discussion of architecture in software design?

The concept of 'engineer' is relevant because it originates from 'ingenuity' in Latin, highlighting the importance of clever problem-solving in software architecture, not just mechanical aspects.

What are the two definitions of architecture provided by the speaker, and how did they merge them into a single definition?

The two definitions are: 1) The art and science of designing and making buildings, and 2) The internal organization of computer components with a focus on data transmission. The speaker merged them into 'the art and science in which the components of a computer system are organized and integrated'.

What is the significance of the example of the Samoan bridge in the context of software architecture?

The Samoan bridge example illustrates the idea that just as the bridge's design enhances the journey, software architecture should not only serve its functional purpose but also improve the overall experience, possibly by making the code more maintainable or enjoyable to work with.

What does the speaker mean by 'messages' in the context of object-oriented programming and distributed systems?

In the context of object-oriented programming, 'messages' refer to method calls on objects. The speaker suggests that viewing these method calls as messages can change one's perspective on code, considering it as part of a distributed system where objects exchange messages.

What is the 'clean architecture' as introduced by Robert Martin, and how does it differ from traditional software architecture?

Clean architecture, introduced by Robert Martin, is a layered approach to structuring software projects where components can only depend on inner layers. It differs from traditional architectures by enforcing strict separation of concerns and reducing dependencies, making the system more maintainable and scalable.

What is the 'Golden Rule' of clean architecture, and how does it apply to the components of a system?

The 'Golden Rule' of clean architecture is to 'talk inward with simple structures, outwards through interfaces.' This means that components within the system should communicate using simple data structures and rely on interfaces to interact with external components or systems.

How does the speaker define 'testability' in the context of clean architecture, and why is it an advantage?

Testability in the context of clean architecture refers to the ability to isolate and test components independently of the rest of the system. It is an advantage because it allows developers to verify the correctness of business logic without relying on external systems or databases.

What is the difference between the 'clean architecture' and the 'jungle architecture' as exemplified by Django?

The 'clean architecture' focuses on strict layering and separation of concerns, allowing for greater flexibility and testability. In contrast, the 'jungle architecture' of Django tightly couples the web framework with the business logic and database, making it less flexible but potentially simpler for rapid development of web applications.

What advice does the speaker give for transitioning to a clean architecture, and why?

The speaker advises against a complete rewrite of existing systems when transitioning to clean architecture. Instead, they recommend making incremental changes, starting with small, isolated parts of the system. This approach minimizes risk and allows for quick rollback if needed, following the example of Netscape's failed attempt to rewrite their browser from scratch.

Outlines

00:00

🏛 Introduction to Clean Architecture in Python

The speaker begins by expressing gratitude for the audience's presence and introduces the topic of 'Clean Architectures in Python,' focusing on the principles of durability, utility, and beauty. They aim to share insights on system design and engage with those interested in the field. The speaker is a developer and blogger who writes about Python, TDD, OOP, cryptography, and infrastructure. They delve into the meaning of architecture, referencing Vitruvius's concepts of firmitas, utilitas, and venustas, and question how often we consider our code in terms of these attributes. The speaker also discusses the etymology of the word 'engineer' and provides a modern definition of architecture, emphasizing the art and science of organizing and integrating computer system components.

05:03

🌉 The Importance of Aesthetics and Longevity in Code

The speaker continues the discussion by questioning the need for code to be useful, durable, and beautiful, using the example of the Samuel Beckett Bridge in Dublin to illustrate the enhancement of user experience through design. They highlight the Unix operating system, designed over 50 years ago, as an example of lasting design. The speaker recommends five key books on system design, emphasizing the importance of understanding the challenges and solutions in system architecture. They also touch on the concept of object-oriented programming as a form of messaging and the significance of considering code as a form of art.

10:03

🔍 Defining Clean Architecture and Its Components

The speaker defines 'clean architecture,' a concept introduced by Robert C. Martin, as a layered approach to structuring software projects. They describe the traditional four layers: entities, use cases, gateways, and external systems, and the rule that components can only depend on inner layers. The speaker explains the importance of avoiding circular dependencies and the principle of 'talk inward with simple structures outwards through interfaces.' They introduce the idea of interfaces in the context of dependency injection and the role of simple structures like data types in clean architecture.

15:07

🛠️ Implementing Clean Architecture with Python Example

The speaker presents a simple Python example to illustrate clean architecture, starting with a use case function in the use cases layer and defining entities in the entities layer. They discuss the use of a web framework, such as Flask, in the external systems layer to handle HTTP requests and translate them into function calls. The speaker emphasizes the importance of the business logic being separate from the web framework and the use of simple structures like dictionaries for communication between layers.

20:09

🗃️ The Role of Repositories and Databases in Clean Architecture

The speaker explains the concept of a repository in clean architecture, which acts as a source of data and can be more than just a database, such as a web API or a set of text files. They stress that the repository is in the external systems layer because it is not part of the core business logic. The speaker also discusses the importance of separating the use case from the database through a database interface, which allows for the use case to be independent of the specific database implementation.

25:12

🔄 The Data Journey in a Clean System and Dependency Injection

The speaker outlines the journey of data in a clean system, from the web framework to the use case and then to the database interface, emphasizing the use of dependency injection to pass instances of database interfaces to the use case. They discuss the importance of the database interface converting database values into entities and the use case adding business logic to these entities. The speaker also highlights the separation of concerns between the business logic and the details of data storage and retrieval.

30:14

📈 Advantages of Clean Architecture: Testability and Customization

The speaker discusses the advantages of clean architecture, particularly its impact on testability and customization. They explain how clean architecture allows for the easy isolation and testing of business logic, web frameworks, and database interfaces. The speaker also touches on the flexibility of clean architecture to accommodate different database systems and front-end presentations without altering the core business logic.

35:16

🌐 Comparing Clean Architecture with Other Architectures like Django

The speaker compares clean architecture with other architectures, specifically calling out Django's 'jungle architecture.' They highlight the differences in how Django's models are tightly coupled with the database and the framework's views are connected to URLs, making it challenging to test and customize without the framework's built-in components. The speaker emphasizes that while Django is a powerful framework, it represents a different approach with its own set of trade-offs.

40:17

🛑 Transitioning to Clean Architecture and Avoiding Rewriting Pitfalls

The speaker advises against a complete rewrite when transitioning to clean architecture, referencing the downfall of Netscape as a cautionary tale. They recommend incrementally applying clean architecture principles to small parts of an existing system and using load balancers to manage the transition. The speaker also suggests considering the specific requirements of a project when choosing an architecture.

45:18

❓ Q&A Session and Addressing Concerns about Duplication and Beauty

The speaker concludes with a Q&A session where they address concerns about potential duplication in clean architecture and the elusive nature of beauty in software design. They clarify that while there may be some duplication, particularly in the definition of models and database interfaces, the separation is beneficial for maintaining a clear distinction between business logic and data storage. The speaker also shares their personal perspective on the beauty of a well-organized system where components interact harmoniously.

Keywords

💡Clean Architecture

Clean Architecture is a software design pattern introduced by Robert C. Martin that emphasizes separation of concerns, making the system more understandable, flexible, and maintainable. In the video, the concept is linked to the principles of firmitas (durability), utilitas (utility), and venustas (beauty) as defined by Vitruvius, suggesting that a well-architected system should not only be robust and functional but also elegant. The speaker uses this concept to guide the audience through the principles of creating a system that is easy to maintain and extend over time.

💡Durability

Durability, as mentioned by Vitruvius and referenced in the video, is one of the three core principles of architecture, alongside utility and beauty. In the context of software, durability refers to the longevity and resilience of the system, its ability to withstand changes over time without needing complete overhauls. The speaker reflects on how often software developers might neglect durability in favor of short-term solutions, using the example of Unix, which has lasted for decades, to illustrate the importance of creating long-lasting systems.

💡Utility

Utility in architecture and software design refers to the practicality and usefulness of a system. The video emphasizes that while developers often focus on creating useful software, the principles of clean architecture can enhance this utility by ensuring the system serves its purpose effectively and efficiently. The speaker uses the term to highlight the need for systems that are not just functional but also designed to meet user needs and business requirements.

💡Beauty

Beauty, in the context of the video, is used metaphorically to describe the aesthetic quality of code and system design. It is suggested that just as physical architecture can be beautiful, so too can software be elegant and pleasing in its structure. The speaker encourages developers to consider the beauty of their code, implying that well-structured, clean code can be as satisfying to create and maintain as a beautifully designed building.

💡System Design

System design is the process of defining the architecture, components, modules, and data flows of a system. The video discusses the importance of system design in creating software that is durable, useful, and beautiful. The speaker shares their views on system design and provides insights into how considering architectural principles can lead to more sustainable and adaptable software solutions.

💡Dependency Injection

Dependency injection is a software design pattern that allows for the separation of concerns by injecting dependencies (like database interfaces) into a class or function at runtime rather than hard-coding them within the class itself. In the video, the speaker explains how dependency injection is used in clean architecture to make the system more modular and testable, by allowing components to receive instances of their dependencies from outside.

💡Use Cases

In the context of the video, use cases refer to specific actions or behaviors that a system should support. The speaker discusses the use cases layer in clean architecture, which encapsulates the business logic of the application. Use cases are central to the design, as they define how the system responds to user interactions and other stimuli, and they should be isolated from the details of data storage and presentation.

💡Entities

Entities in the video are used to represent the core business data or concepts within the system. They are the building blocks of the business logic and are distinct from the data storage mechanisms. The speaker explains that entities in clean architecture are known to all other components and are used to encapsulate the data that is relevant to the business domain.

💡Gateways

Gateways in the clean architecture model refer to the components that handle external interactions, such as database access or communication with web services. The video script mentions gateways as part of the outer layers of the architecture, which are responsible for translating between the internal system components and external systems or data sources.

💡Testability

Testability is a measure of how easily a piece of software can be tested. The video emphasizes the importance of testability in clean architecture, as it allows for the isolation of components such as use cases and gateways for individual testing. The speaker argues that clean architecture enhances testability by separating business logic from external details, enabling developers to test core functionalities independently of external systems.

💡Integration Test

An integration test is a type of software testing that checks the interfaces between units/modules to ensure they work together as expected. In the video, the speaker mentions integration tests in the context of testing the repository interface with a database, which is necessary to ensure that the system components work correctly when combined, even though it might be a slower process due to the involvement of actual database operations.

Highlights

The concept of clean architecture in Python is introduced, emphasizing durability, utility, and beauty in system design.

Vitruvius' principles of architecture are related to modern software design, suggesting that code should be durable, useful, and beautiful.

The speaker's background as a developer and blogger is shared, focusing on topics like Python, TDD, and infrastructure.

Architecture is defined as the art and science of organizing and integrating computer system components.

The importance of considering code as an art form, alongside science, is discussed to encourage better design practices.

Examples given from traditional architecture and the Unix system illustrate the principles of useful, durable, and beautiful design.

Five influential books on system design are recommended, with an emphasis on understanding the patterns and challenges in system architecture.

The idea that object-oriented programming is about objects exchanging messages is related to distributed systems and microservices.

Clean architecture is explained as a layered approach to structuring software, with rules on dependencies and component visibility.

The 'talk inward with simple structures, outwards through interfaces' rule is introduced as a key principle of clean architecture.

A simple Python example demonstrates the application of clean architecture principles in code.

The separation of business logic from external systems like databases and web frameworks in clean architecture is highlighted.

The advantages of clean architecture, particularly in terms of testability and customization, are discussed.

A comparison is made between clean architecture and other architectures like Django's, noting the differences in approach and philosophy.

The importance of incremental changes when adopting clean architecture is stressed to avoid the pitfalls of rewriting systems from scratch.

The speaker offers a free book on clean architecture in Python, demonstrating the concepts with practical examples and TDD.

Questions from the audience address concerns about potential duplication in clean architecture and the elusive nature of beauty in software design.

Transcripts

thank you for being here so the title of

my talk today is clean architectures in

Python A Tale of durability utility and

beauty

and my goal today is so I'm here because

I want to share my views on system

design

and give you an example of what I

discovered and what I learned and maybe

meet people who are interested in system

design as well

so this is me well not a picture of me

but you know I'm a developer and a

blogger you are welcome to visit my blog

I usually write about python obviously

tdd object oriented cryptography and

infrastructure these are the main things

I like to write about

so today it's a talk about the clean

architecture and I want to start

with a question thinking a bit about

what architecture is

we mentioned architecture many times the

architecture of a system or what is it

what is it definition

so I found this in a book that has been

around for a while the architecture it

means about architecture

it's been written a couple of thousands

years ago

the two views who was a Roman architect

and engineer

says that architecture is about firmitas

utilitas and venustas which translated

in Modern English is durability

utility and beauty

so Vitruvius says that architecture is

about things that are durable something

that has to last

has to be useful has to be beautiful

and for me this was very interesting

because how many times

do you think about your code as

something that has to be useful

beautiful and durable

useful yes nobody wants to write

something that is useless

but what about durable

we change framework every two years now

right every six months I don't know so

having something that lasts

and beautiful that's the thing I'm

mostly concerned about

it's interesting let me mention this

that vituvius was an engineer and an

architect

and

these two professions don't go together

that much nowadays um it's interesting

to think that engineer the word comes

from engine

but engine comes we we when we discuss

about engines we think about something

mechanical

but engine actually comes from

um Ingenuity in Latin it's from

cleverness

so it's less about mechanical things is

more about solving a problem in a clever

way

anyway I went on and I checked also on

the dictionary Modern English dictionary

and I found these two interesting

definitions of architecture

one is the Art and Science of Designing

and making buildings

and the second one is more

concerned with computers and it says the

internal organization of computers

components with particularly the

reference to the way in which data is

transmitted I like these two definitions

I wanted to come up with something a bit

more compact

so I try to merge them into this which

is the Art and Science

in which the components of a computer

system are organized and integrated

I want to stress

Art and Science

how many times do you think about what

you do daily as Art and Science

as science yes data science computer

science

mechanical path right

what about art

when do you look at your code and think

this is art

why is it not data art it's not computer

art not as in you know painting

something with the computer but our code

is beautiful or it can be

and the other two interesting words here

are organized and integrated because a

system architecture when we when it

comes to computer science is all about

where components of the system are and

how data flows between them

so this is the integration part

cool now that I defined architecture

the following question is do we need it

so do we need things our code to be

useful durable and beautiful

and this is up to you I positive about

this otherwise it wouldn't be here

but I want to give you a couple of

examples and one comes from the

traditional architecture and it's the

page that is in front of this building

the Samoa backup page

it's interesting I was looking at it

these days and I thought

does this bridge have to be shaped like

an heart

if the requirement of the page is just

to take cars from one side to the other

it doesn't have you just need a plain

Bridge right something that I could

design because I don't know anything

about which design

but if the requirement is to make your

journey better

well being shaped like a hub in Dublin

is a nice thing to have

so this is Food For Thought maybe you

know like what is the requirement of

your code what what is it that you are

creating when you create a library do

you just create some Machinery or do you

create something to make the journey

better

the other example I have it's about

something lasting a long time

um

the Unix system it's an operating system

was designed in 71 so 50 years ago

and it was well thought

not everything in a unique system is

perfect okay sometimes it's far from it

but it was well thought

so well designed that I am running a

Linux machine and Linux is a clone of

Unix and many of you use Mac OS which is

a derivative of Unix 50 years

so again how many times do you look at

your code the code that you write and

you think

in 50 years people are still we will

still use this code or at least these

ideas

anyway I'm not the only one who thinks

that system design is an interesting

thing

um there are much smarter people than me

who wrote a lot of books there are vast

literature about this I selected five

books that I read which I believe are

interesting about the topic

some of these are door stoppers pretty

thick okay so if you are not up for the

challenge I recommend retrieving at

least the two in Orange so design

patterns and Enterprise Integration

patterns at least

read the introduction

and I'm not joking the introduction to

these two books the two introductions

are short

but they give you a narrative of the

challenges and some of the solutions

that you might have when you design a

system

and I was

um I was really

you know flabbergasted when I read the

introduction to design patterns because

it was like Hey I faced these issues

every day

I want to mention another thing about

Enterprise Integration patterns this is

a book about messaging message based

systems more about distributed systems

if you want

but it's interesting that message based

systems microservices for example

this software design and languages they

are all in the same league they share a

common trait

which is messages

object oriented programming and you can

quote me on this is supposed to be

about objects that exchange messages

so every time you call a method on an

object you are sending a message to

something

so it sees a distributed system

and if you if you think about that if

you when you code in Python if you think

about messages this might not change the

code itself because you are still

calling methods but it will definitely

change the way you think about your code

it's a bunch of objects it's a

distributed system and I'm exchanging

messages anyway this might be for

another talk another time now that I

defined architecture and I decided for

you that we need it

let me Define clean because this is

about a clean architecture

um I found it

easy to define the opposite of clean the

picture in the background if you look at

that system

you can definitely say this is not clean

it's not tidy good luck maintaining

something like that okay they said pull

the green cable yeah good luck okay this

is an extreme example probably but

sometimes our code looks like that right

you change something and suddenly

everything crashes nothing works anymore

instead in a clean system with a tidy

system if you want you have these

characteristics for for each component

you know the three W's right you know

where it is it's easy to find the

component in the system it's isolated

you know what it is from the name for

example and you know why it is in the

system you can say why it's been

included in the pictures in the

background there are two just you know

hardware systems um and they are tidy

it's easy to trace where our cable goes

some are color coded so it's easy to

understand you know why they are there

what they are what they are doing

okay now that I Define the claim

architecture in terms of the words let's

go for the concept for an example

so what is the clean architecture

it is a concept that was introduced by

Robert Martin uh some years ago Herbert

Martin is a system engineer system and

designer you know a developer and I'm

not here to advertise Robert Martin's

work mostly because Robert Martin is

very good at advertising himself you

know so

um but I'm gonna use the same name uh

it's it's important for me to stress

that the concepts that Robert Martin

dubbed the clean architecture uh predate

his work so they have been around for a

long while

so let's call it the clean architecture

but it's a set of Concepts such and that

predates what Robert Martin did what is

it it's a layered approach so it's a way

to structure your software

um project right you your code it's

layered and it's circular

so in the traditional

[Music]

say definition we have four layers you

can have more of them but this these are

the traditional ones entities use cases

gateways and external systems

what happens is that when you create

something in a clean architecture this

something this component will belong to

one of these layers and there are rules

there is actually one simple rule one

rule at least

which is that your component can see

I'm going to Define what C is can see

only what has been defined in an inner

layer

so if you create something in the use

cases layer or ring

you can see everything that has been

defined in the same layer use cases and

everything that has been defined in

entities you are not allowed to use to

access anything that has been defined

outside

and that that has to do with

dependencies

the problem of unclean systems remember

the cables before is dependencies

between

components when you have a component

that depends on other components and

these other components depends on other

components and you can't trace these

dependencies and sometimes they are

circular dependencies

in a clean architecture there are no

circular dependencies

the Golden Rule I'm going to introduce

it now and then show you an example that

clarifies it is that you talk inward

with simple structures outwards through

interfaces what does it mean simple

structures

are data types that have been defined

in inside so for example again something

in use cases can use data types and I

mean data types in Python for example

you can instantiate them if they have

been defined in use cases and if they

have been defined in entities

if something has been defined in

external systems you don't see it you

can't instantiate it

interfaces interfaces have to do

um so they they are related to

dependency injection which is something

I will introduce later

what is an interface

um going back to what I said about

objects and sending messages when you

send a message to something you expect

it to be able to receive that message

when you call a method on an object you

expect that object to well have that

method right otherwise you'll get an

exception in Python we don't have an

explicit way to State infrastructure in

interfaces okay to create them even

though we have now protocols we have

abstract based classes there are many

ways to work with interfaces and we can

discuss about this another time because

there is no enough time today anyway I'm

coming back to this slide later when

after the example

the example today is simple

the code I will show is python it's

valid python but I stripped all the you

know error checking a lot of things that

are not useful for now obviously they're

real the real code is a bit more

complicated

my use case is to retrieve a list of

items is very simple

when do we want to achieve a list of

items I don't know you have a social

network and you want to retrieve a list

of posts right or you are Amazon you

want to send Using to show a list of

proper items that you are selling

in this example my use case is just a

simple function it exists in the use

cases layer

and for the time being it doesn't do

anything

then I Define some entities entities are

models okay they represent real items

that are in my business logic

so in this case for example something

with a code and a price okay just a

simple class that captures data

encapsulates data

the entities leave in the entities layer

and they are known to all other

components

it's 2022 so we probably want to build a

web application but this is not required

okay it's just an example

the web application

requires a web framework because I don't

want to implement you know the logic to

deal with HTTP requests and all these

things there are smarter people who did

for me

in this case I'm using flask

but I can use any other web framework

the web framework exists in the external

systems and I want to say a couple of

things about this

um

I mentioned business logic before the

business logic is what you Market

is the core of your application

the web framework is not generally

speaking part of your business logic you

are not marketing Django you're not

marketing flask you are marketing a

social network your marketing items

delivery whatever right

so it's reasonable for the web framework

to be in a very external layer where we

use it but we don't manipulate it

the core

um the most important thing in a clean

architecture I would say in any

architecture is the business logic this

is what 99 of your time should go

anytime you every time you spend you

know configuring external systems it's

not wasted but it's not given to the

core of your business

anyway this is the web application the

web framework

now what is the task of the web

framework

the web framework is there because it

wants it has to translate HTTP requests

into course

this is all a web framework has to do

granted it's not an easy task okay there

are many things involved but this is

what the web framework should do get an

HTTP request and transform it into a

call for example for a python function

in this case this is exactly what I'm

doing I'm calling the use case which is

a function

here you see that the web framework

communicates with the use case with

simple structures what does it mean in

this case I'm using request args for the

sake of you know Simplicity it's just a

dictionary

and it's a simple structure because it

has been defined in the in the language

right so it it might be an entity or it

might be something that the language

defines all these things exist in Python

so whatever is defined in python as a

core language is available

so I'm sending to um the use case as

simple structure something that the use

case can understand

for example I shouldn't send anything

that is defined in the web framework

some structure that has been defined

there a type that flask uses to manage

an HTTP request because the use case

doesn't do anything doesn't know

anything about HTTP request and it

shouldn't know anything

okay then we have to retrieve items and

data data is stored usually in a

repository and we are used to think

about the repository as a database which

is what I have in the example here

but I want to stress that a repository

is much more than a database for

starters it doesn't have to be a

relational database it might be no SQL

mongodb for example or it might be

something different for example a web

API

it's a source of data right you code the

API you get data it sucks exactly what

you do with the database

it might be a bunch of text files which

is a rudimentary database it might be a

hardware sensor that is a source of data

it's a repository okay so let's think

about it as a database I'm going to say

database probably a lot of times but the

repository is the right word here

and the database the repository exists

in the in the external systems layer

because again it's something that is not

part of my core business it's not my

business logic

in system design we usually call the web

framework the database everything that

is outside as a detail we call it a

detail and many many times it surprises

people because they are like what

details I mean configuring postcodes you

know and all these things is complicated

it's not it's not secondary it's not

just so simple a detail means that it's

not part of the business logic this is

not what I'm marketing if my product

works with postgres or works with

mongodb

you are not concerned you as a client

are not concerned

your problem is to receive a service

so this is why it is a detail while the

specific algorithm I use for my

recommendation system for example is the

core business is what you like of my

product

okay so this is the difference between a

Core Business logic and a detail so the

database is a detail even though it

might be complicated

however itex is in the external systems

so as I said before the use case is not

allowed to communicate directly with the

database in Python terms

um the use case is not allowed to

instantiate anything that is

tightly coupled with the database that

is connected with the database directly

because if I had code in my use case

something which is I don't know postgres

a library for to interact with postgres

or to interact with mongodb I am

coupling my use case with the

implementation of the database

and this is not good because at that

point I have my core business my core

business logic

coupled with a detail which might change

my mind might not be the same thing in

time

so I create an interface this is um in

this case we are talking about python

it's an object that provides a facade

okay so a set of methods that are common

to databases

so the web framework instantiates the

um

database interface or the repository

interface the web framework can do it

because it's in an outer layer so the

web frame sees can see what's in the

gateways

and passes the so it sends the in

instance of the possible in this case to

the use case this is called dependency

injection if you are not familiar with

the concept I have a slide for that

later but look at it

the use case the code of my use case

doesn't have postgres or apple

hard-coded in it I'm receiving an object

that provides methods that might be an

object of postgres repo mongodb repo

type whatever the important thing is the

interface

or the set of methods that are that

thing provides

cool now internally I'm in the use case

now and I have finally my business logic

okay this is where my brain comes into

play right I have to write something

that implements the recommendation

system the whatever filtering you want

eventually sooner or later I have to use

the database interface to retrieve the

data so in this case I'm calling repo

list okay passing the parameters that I

received from the HTTP request

or from outside I should say right where

they come from is not important

the business logic might be for example

to prepare the parameters to add some

filtering you know or to do something

else

anyway back to the database interface

I'm calling repo list okay here right

police so I'm in the database interface

now and the database interface is

tightly coupled with the database that

is postgres repo so it's it has been

designed to work with postgres okay it's

in the name

so the two

um communicate with a specific language

in this case I'm using SQL Alchemy it's

an object or additional mapper but

eventually I'm in um in a mindset of

querying a relational database this is

what I'm doing here okay I'm I'm

committed to relational databases at

this point and this is what I'm doing so

the two things are tightly coupled

or the database interface does is to as

I said the query the database and then

it transforms the output of the database

the database just sends me values right

it's it's SQL so just standard types

known to SQL databases

the database interface has the task to

convert those values into entities

because at this point everybody can see

entities as a layer it's a very inner

layer so the database interface can say

okay these SQL values that I get become

items

as in items that I defined

and these items are sent back to the use

case as a result of the repo list at

this point I can add more business logic

okay just to say that obviously if you

want to if you have to call your

repository you can do it at any time and

your business logic is around that code

is where you augment these results okay

with your algorithms with your

cleverness

your product

at this point the use case has the

results and it can send it back to the

web framework or to whatever called it

and the web framework so this is again

sorry entities the web framework can

knows about entities so this can still

be

um

an entity a model that I created

the web framework again has one task

that of converting the entities which

are specific models of my business into

something that is understandable outside

for example Json

okay this is the task of the web

framework my use case doesn't know

anything about Json it doesn't care

because the use case is okay with

entities it's part of my business

this is the Journey of the data in a

clean system at least in this example

in a clean architecture

I want to go back quickly to

um

the initial slide about the Golden Rule

right talk inwards through simple

structures and outwards through

interfaces have a look at this code

these are two different possible

implementations of a use case the second

one is the one I used the first one is

the incorrect one if you want

why is it incorrect it works okay first

of all so it's not incorrect from that

point of view

but these Calpers my code the code of my

use case

with the postgres rifle it means that I

can't use anything else or if I want to

use something else I have to touch the

use case but the use case is your

business logic and it shouldn't be

touched because you change something

which is a detail where you store data

okay the second one instead and this is

a good example I I hope of dependency

injection

is when you create something outside

and then you pass an instance of it the

instance has been instantiated outside

so the part of the code that is coupled

with a type the postcode so I put it

outside in this case is the web

framework

your use case just receives an instance

something that can accept a certain set

of messages does it make sense I hope so

this is what happens in a clean

architecture simple structures inside

interfaces outside

cool

um I want to tell you about the

advantages of the clean architecture why

should I go through all this pain

and there are two specific things I want

to mention

um the first one probably the most

important one for me is testability

a clean architecture a software designed

with a clean architecture can be tested

very well

what do I mean by that

um look at the use case

I can easily isolate the use case from

the web framework and from the database

interface it's just an object that

receives a repo

and some parameters and returns some

results

so what I can do is to pass a dictionary

you know of parameters

a mock database interface so something

that pretends to be the database

interface but is not connected with any

database it's just you know amok it

returns a fixed set of data

and check that my business logic Works

given that input gives some output

this allows me to test my business logic

in isolation I don't need the database

to test my business logic I don't need

the web framework because these are

details my business logic is not about

details

at the same time I can test the details

because yeah details but they are part

of the implementation so I have to test

that my web Frameworks

and the web framework can be detached

from the use case

because the web framework the only task

is not a simple task again but the only

task of the web framework is to accept

HTTP requests convert them into calls

get the result of this code and convert

it back to an HTTP response as I said

it's not simple I have to test that this

works and I can do it in isolation

and last I have to test I can test my

repository interface this requires

the database because this is an

integration test okay I'm testing that

my the facade of the database works so I

need a database running this might be a

slow test you know that you might run

just sometimes again I want to stress

this I see it too many times when we

when it comes to testing in particular

with web Frameworks

we end up testing the database

so we store a model then we retrieve the

model and we say hey it works thank you

very much this means that Django or

whatever framework you're using works

that postgres works but this is not what

you are supposed to test

these are you know provided by third

party is not part of the local business

the second Advantage

is about

[Music]

um

customization I would say

look at this in this case I have two

different use cases one is to list items

and one is two list users a phone sub

for some reason from for example for

performances reasons I store the users

in a mongodb which is not relational

okay so I can't use it with a SQL

Alchemy for example because it's not SQL

but this is not a problem in a clean

architecture because my use case is

customized it just has to receive a

different object okay that is

instantiated by the web framework

um pay attention that this might happen

inside the same use case so those use

cases those two use cases might be the

same and you might have some logic

inside might be part of your business

logic that says well in this case I go

and fetch things from repo a in this

case I go and fetch things from repo B

performances for example okay but these

repos are something that you get from

outside as you see here I'm instantiated

them

in the web framework not in the use case

and the other side of this is that the

web framework is just one of the

possible front ends and with front end

now I don't mean reactors similar things

I mean the way you present your results

to the client it might be a common line

interface it might be a web protocol or

something else

because I just need to code the use case

and translate the output of the use case

into something that is Meaningful for my

front end okay HTTP request for a web

framework something else for example

text for a command line interface

okay at this point

um I want to draw a comparison with an

architecture that we or at least many of

you probably know which is the jungle

architecture Django is a amazing web

framework

well known in the python Community it

has a different architecture it's not

the clean architecture this doesn't mean

it's unclean maybe

um well yes it's unclean from giving

given the definition it's unclean

of what I mean is

I don't want to say it's bad okay I'm

I'm coming back two days later I just

want to draw the comparison for now

um well Django has models these are

similar to entities superficially

speaking they just represent part of my

business right I have items I have I

don't know books you know films

something that I'm marketing

I have business logic obviously

otherwise why should you use Django you

have something to market right something

to sell

business logic in Django is usually

implemented in views but it can be

implemented in functions that are called

in views okay so this is similar if you

want to what I did before with the clean

architecture

okay for the first big difference Django

as an uh om an object or additional

mapper which is if you want a Gateway

it's an interface

because if you use

um

MySQL if you use postgres your views

don't change right so you are using an

interface you are using something that

masks the details of the underlying

database

however the object relational mapper the

name says it all it is an interface to

relational databases and it's not easy

to use Django with no relational

database always something else okay a

web API

because of the OM is customized for

relational databases and this is

different in a clean architecture

because the gateways is a more generic

definition of interface

last two components the database

um which is an external system

which is also tightly connected with

models because Motors in Jungle can be

saved everything from the database

natively so the models are connected

with the database they are aware of the

database

what is the drawback of these that when

you test your Django application you

need the database

it is possible to test it without the

database okay but you are sort of

fighting against the framework you're

doing something that the framework

doesn't want you to do so again it might

not be bad but it's different okay so

there is a big connection between two

layers one is the inner layer one is

outside

and the same happens for the web

framework itself as in the part of the

framework that deals with HTTP HTTP

request responses

because that is connected with the

business logic as I said before you

usually Implement your business logic in

views and Views are specific things

provided by the web framework they are

connected with URLs right

cool so so far this is the jungle

architecture just to show you that there

are different approaches to the things

and as I said this might be a good

approach it's not bad it's just

different

okay let's assume I convinced you okay

in 40 minutes you are like yes the clean

architecture is the way to go so I want

to go back home and convert everything

you know to the clean architecture well

um don't do it

so oh if you want to do it to do it the

right way so I always recommend to um

you know remember what happens to what

happened to Netscape when they decided

to rewrite the whole thing from scratch

they lost everything have you heard of

Netscape lately no you know well it

resurrected at a certain point but you

know uh it's a sad destiny that of

Netscape and it's for a bad choice so

don't do the same Choice migrations

happen one step at a time

so my recommendation if you want to try

these Concepts is to isolate part of

your system some something you know tiny

in your system and re-implement it maybe

with a clean architecture something that

doesn't affect the rest of the of the

architecture

remember that when it comes to web

applications you have load balancers

they are your best friends you can

always root a requests to another system

okay and you can go back quickly if it

doesn't work

final slides is this the definitive

architecture so

done okay it's the perfect architecture

we don't have to do anything else go and

Implement everything with the clean

architecture thank you very much

so

the answer to this question is in my

opinion the answer to any computer

science question ever and it is

it depends okay it depends on many

things it depends on your requirements

for example when it comes to the clean

architecture versus something else for

example the jungle architecture I tend

to show this slide you are the

crossroads between these two options

Lego versus Playmobil on the right you

have something that works out of the box

and it's it's very nice you you can play

with it it's amazing you know I don't

play with it nowadays but I remember I

have fun memories

you want a farm you get a farm it's

customizable up to a certain point you

can move things around okay

on the other side on the left you can

build whatever you want

but you are on your own

so it depends what are you constrained

what do you want to achieve can you mix

and match the two yes you can okay so

this is my recommendation always

whenever you design a system always stop

and think look at the requirements don't

go for a solution out of the box it

might be the right solution but you have

to be you know clear that why it is the

right solution

uh reading last two slides I wrote a

book about this uh Concepts clean

architectures in Python it's a free book

it's available there

the example I showed you today comes

from the book there I implemented it

properly with tdd all the way

a lot of error checking so the whole

book is about that example okay just

write even a list of objects I

implemented it with postgres and mongodb

just to show that it's possible to use

different databases

for the Euro python so for this week and

the next week I teamed up with some

friends and I'm offering the book and

other books for free it's a bundle worth

of 60 dollars so you are free to follow

us on Twitter and you can check the URL

on the in Pub to get the bundle for free

with that I'm done I hope it was useful

thank you

yeah thank you very much Leonardo for

that very inspiring talk we have a few

minutes that are available for questions

so if anybody has a question we have a

microphone here or just quickly go to

that microphone and ask a question I'll

be around for the next two hours so feel

free to get in touch okay yes uh hello

thank you for the really nice

presentation and why I try to follow the

layered architecture the one thing that

I always struggled is with

so if you want to really follow this

then it seems like you have a lot of

duplication so you have to have the

models in the core of the business that

your business or your cases are using

and then you want to persist also those

models into the database or somewhere

else they need to have some kind of

definition of how this happens with some

bookkeeping data and potentially the

duplicate the definition of the original

data so since there's a application so

do you have a suggestion how to avoid

that or maybe make it less painful to

implement the clean architecture

I don't think there will be duplication

we might we might talk about this later

there is definitely a lot of message

passing so if that is what you mean by

duplication yes the same data is going

around a lot which is part of the

drawbacks of the clean architecture

there are a lot of layers that is my

impact performances like you don't have

a direct access to the database

but in terms of duplication I I'm not

really sure what you mean so if you want

to expand on that for example when in

the example at the show for the jungle

that is you define the model once and

then this that's also the definition of

how the table would look like and

majority of RMS work the same way so you

have single source of proof that defines

basically the layout of the data in the

database as well as the layout of the

model that you're working with and for

the data heavy application that's really

convenient and very simple to like work

with and Define your system so if you

don't want to use that then you need to

have I definitely see what you mean

thank you

um now I understand yes it's true that

for example the model I use in entities

correct me if I understood the wrong way

is duplicated in the database interface

because this is what I'm storing exactly

it's true there is no way to avoid it

because this is a feature

as in I am splitting the model The

Entity if you want as in a business

entity and the entity has something that

is stored in the database

I agree this is more work

and there is no way to avoid it because

it's considered a good thing

again it's part of the it depends the

requirements you might think that in

your business logic this separation is

not needed or it's Overkill and you're

free to go with a different architecture

but the idea if we want the extreme idea

is to split these two things because

they might exist in the same space but

they are not the same thing one thing is

the business logic one thing is how I

did the business entity if you want and

one thing is how I store it

okay thank you thank you very quick

final question

hi hi Leonardo thank you you're welcome

I really appreciate your emphasis on

beauty and art in terms of software

um with clean architecture I can see the

benefits of say durability uh utility

how it by making a architecture clean do

I get Beauty out of the box or is there

something more elusive uh making

something beautiful it might be a bit

more elusive

um you know beautiful beauty is to be

defined

to be honest when I was working on the

book and I came up with the example and

you know I was looking at the projects

where components were how they were

interacting between them a certain point

my feeling and this is pretty personal

it was like this is this is really

beautiful it clicks it works and this is

what I meant as in Beauty for me it

might be subjective okay definitely it

doesn't shine doesn't come in us you

know but the beauty of that system for

me is that it's again it's tidy I know

where things are I'm confident that when

I'm touching something and touching just

the little Universe around that

component and not other things

this works for me and this is the beauty

in that architecture for me thank you

very much for the questions and let's

have another round of applause for

Leonardo thank you