---
title: 'Clean Architectures in Python - presented by Leonardo Giordani'
source: 'https://youtube.com/watch?v=C7MRkqP5NRI'
video_id: 'C7MRkqP5NRI'
date: 2026-06-19
duration_sec: 0
---

# Clean Architectures in Python - presented by Leonardo Giordani

> Source: [Clean Architectures in Python - presented by Leonardo Giordani](https://youtube.com/watch?v=C7MRkqP5NRI)

## Summary

Leonardo Giordani presents the clean architecture concept for Python systems, drawing parallels to Roman architect Vitruvius's principles of durability, utility, and beauty. He explains the layered architecture, dependency inversion, and the golden rule of communicating inward via simple structures and outward via interfaces, using a concrete example of a web application that retrieves a list of items.

### Key Points

- **Architecture Definition** [0:05] — Architecture is defined as the art and science of organizing and integrating components of a computer system, emphasizing the three qualities from Vitruvius: durability, utility, and beauty.
- **Why Architecture Matters** [2:51] — Draws analogies to the Sydney Harbour Bridge (beauty) and Unix system longevity (durability) to argue software should be useful, durable, and beautiful.
- **Core Concept: Clean Architecture Layers** [5:09] — The clean architecture (by Robert Martin) consists of four layers: entities, use cases, gateways, and external systems. The rule is that inner layers know about nothing outer; dependencies point inward.
- **Golden Rule of Communication** [10:22] — Talk inward with simple structures (e.g., Python dicts) and outward through interfaces (dependency injection). Use cases should not instantiate database objects directly.
- **Example: Use Case Implementation** [16:08] — A use case function receives a repository interface via dependency injection, calls repo.list() to get entities, and returns the result. The web framework handles HTTP ↔ use case translation.
- **Advantage 1: Testability** [22:02] — Clean architecture allows testing business logic in isolation by mocking the repository interface. Details (web framework, database) can be tested independently.
- **Advantage 2: Customization and Flexibility** [25:01] — Different data sources (SQL, MongoDB) can be used for different use cases without affecting business logic. The same use case can be served via web CLI or HTTP.
- **Comparison with Django Architecture** [28:01] — Django's ORM is tightly coupled with models and the database, making it harder to test business logic without a database. Django is more Playmobil (ready out of the box) while clean architecture is Lego (more flexible).
- **Migration Advice** [33:35] — Do not rewrite from scratch (Netscape's mistake). Instead, isolate a small part of the system, re‑implement it with clean architecture, and route requests gradually using load balancers.
- **Final Verdict: 'It Depends'** [34:33] — The clean architecture is not the only correct answer. The choice depends on requirements: Lego (clean architecture) vs Playmobil (Django). Mixing both is possible.
- **Resource: Free Book and Bundle** [38:36] — Leonardo wrote a free book 'Clean Architectures in Python' which contains the example shown, implemented with TDD. During EuroPython 2022 the book and others are free for a limited time.

### Conclusion

The clean architecture is a powerful pattern for building maintainable, testable Python applications, but it is not a one‑size‑fits‑all solution. Developers should evaluate their project's requirements before committing to any architectural style.

## Transcript

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