Clean Architectures in Python - presented by Leonardo Giordani
Summary
TLDRIn 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
π 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.
π 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.
π 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.
π οΈ 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.
ποΈ 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.
π 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.
π 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.
π 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.
π 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.
β 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.
Mindmap
Keywords
π‘Clean Architecture
π‘Durability
π‘Utility
π‘Beauty
π‘System Design
π‘Dependency Injection
π‘Use Cases
π‘Entities
π‘Gateways
π‘Testability
π‘Integration Test
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
Browse More Related Video
How I structure my next.js applications
Vitruvius
Top 5 Most Used Architecture Patterns
Five Things Every Developer Should Know about Software Architecture β’ Simon Brown β’ GOTO 2020
Monolithic Architecture In Hindi ( Complete Explanation )
Hexagonal Architecture: What You Need To Know - Simple Explanation
5.0 / 5 (0 votes)