should you buy this book that's the
question that i want to answer today
and what is this book well this is clean
architecture it's by
uncle bob probably one of the most
famous programmers
in the world he wrote a whole bunch of
other books like clean code and clean
coder
and he kind of knows what he's talking
about now this book is kind of popular
on the internet it's all over the place
it's on a lot of programmer reading
lists
and currently it's ranked number 38 on
amazon's programming best sellers list
i don't know if that's good but that's
what number it is now i'm going to help
you decide whether or not you should buy
this book and in order to do that i'm
going to divide this into three
different sections
first i'm going to talk about what this
book is about just a little bit about
robert martin and generally what the
themes are in this book
then i'm going to talk to you about the
key takeaways that i took from this book
personally
and then finally i'm going to give you
my summary and whether or not i can
recommend it or not for you to read
so first of all who is this book even
for well it's for software developers
if you're a beginner software developer
especially even if you're
a more mid-career or veteran software
developer i think this
book is beneficial to all different
skill levels
talking about this personally i kind of
learned a lot of the concepts of
software development and software
architecture just by
kind of going into the trenches and
experiencing it and
seeing what it looked like in real life
and i can tell you that when i read this
book after the fact a lot of the
concepts and the principles that it
teaches you are very applicable to real
life a lot of these things
that it teaches you are in fact how it
works um so
looking at this in retrospect i wish i
knew about this stuff earlier i wish i
like to read more as i
as i like to read now but take that as
you will and the essence of the book is
that
often when we're working with a code
base you you know
if it's good or bad right like it's
either good and you know that because
it's easy to add features it's easy to
change things
documentation is always up to snuff
everything is just
gravy and when it's a bad code base you
know the complete opposite happens you
often just end up banging your head
against the wall trying to
sort out trivial problems or solve small
things that shouldn't take a long time
um and so the idea with this book is
teaching you the kind of pillars or the
principles
that you need to apply to your daily
life so that you can get your code
into the good state into the state that
we all want our code to be where it's
easy to maintain
easy to develop new features for etc etc
so in other words this book is about
keeping you on the path if you're on the
path and kind of course correcting you
or teaching you the principles to course
correct yourself
if you're working with a problematic
code base uh that being said it's also
great if you're just starting out
because this will teach you a lot of the
principles that you need to know about
in terms of how to set up your project
and kind of define the core entities
that in the end are going to end up
being the thing
that drive your architecture so that's
what this book is about now i want to
talk about the
kind of important bits from this book
and the key takeaways that i took from
it personally
and it starts out by talking about a lot
of the basic concepts that you learn in
any standard computer science program
so things like object oriented
programming things like functional
programming
procedural programming structural
programming all these different types of
programming
and it turns out there's some principles
that you can apply from the different
programming types
to your architecture so that's why he
spent some time talking about
now along that same line the book talks
about these solid principles
and there's five solid principles and
these are the kind of bible for software
developers in terms of
kind of principles that you apply to
your daily life when you're building
architecture and then kind of guide some
of the key decisions that you need to
make
so if you don't know what solid is i can
just kind of recap them for you so the s
in solid stands for the single
responsibility principle and this is the
idea that a class would be responsible
for one thing
one domain the o in solid is for the
open
close principle which is that a class
should be open for extension but
closed for modification the l is the
liskov substitution principle which
basically means you should use
polymorphism whenever it's possible
if you don't know what polymorphism is
i'd highly suggest you watch the video
and just look up a definition
it's a very useful concept in a lot of
these conversations
the i is for the interface segregation
principle which is that it's usually
better to have
multiple interfaces for different use
cases as opposed to one overloaded use
case
and then the d is for the dependency
inversion principle
and this means that you should only
depend on abstractions whenever possible
and your higher order component should
never depend on your lower order
components
so after he talks about that he talks
about a lot of how these principles
apply to some software architecture
concepts
so he brings in a lot of the talk about
service oriented architecture and if you
don't know what service oriented
architecture
is let me just give you the brief about
it so service oriented architecture is
the idea that you separate your
application out into different domains
different components
uh so say for instance if we're working
with a credit card application that's
responsible for processing customer
transactions
we may say okay maybe it makes sense to
have a service called the transaction
service
and this service is responsible for
being the ledger this is going to handle
kind of the commits to the database and
going to be your single source of truth
whenever transactions are accepted and
committed in your system
then in the middle maybe you have an
authorization service and the service
can be responsible for
simply authorizing whether or not a
transaction is possible
and then over on the side here you can
have a different service that's
responsible for fielding customer
requests
to authorize those requests and finally
commit those to the database whenever
they are authorized so that's kind of
how you can separate out a fairly basic
example into service oriented
architecture so he talks a lot about the
benefits of this you know decoupling
independent deployments
you can move a lot faster in service
oriented architecture now he also does
mention that a lot of companies don't
have the luxury or the
resources to build out service oriented
architecture so he suggests how to kind
of
organize and lay out your source code
dependencies and your package structures
in a way that lets you extend
those into service oriented architecture
friendly
format if you decide to go down that
path and i thought that was a very
interesting idea and one of the side
effects
of going through this exercise of
cutting up your service into different
roles and kind of assigning them
different responsibilities is that you
end up building
modules and that's another common theme
of this book it's the the promotion of
this idea of
modules or components that are
responsible for specific things
now the next major section that he talks
about is regarding
details and he makes this argument that
a lot of the things that we worry about
at the beginning of a project
don't actually matter that much until
you're further along in the process
so the idea is to delay these types of
decisions to the last possible moment
to give you the most flexibility and
i'll give you a perfect example on this
uh in the book he's talking about
building this
application with his son and he's
talking about how they didn't even have
a database for this application
up until like a couple months before
they were going to launch this thing
and the reason they need one is because
they built an interface that sits
in front of the database so now all the
calling code doesn't have to know about
the the implementation of the database
or even whether or not
you know it's a nosql database or a
mysql database
or a graph database or whatever it is it
doesn't matter
that decision can be delayed up until a
very later point
now for a lot of applications that's a
very wise thing to do because
us as developers we get obsessed with
certain types of technologies and we're
like hmm which one should we use here
which one's a better idea and really
that kind of stuff doesn't really matter
until a later point in time
uh he even mentions that in this kind of
example he was talking about they didn't
have a database they were writing to
flat
files for a very long period which i
thought was just fascinating
and another key part of this discussion
is like drawing boundaries that's what
service oriented architecture
kind of thinking allows you to do it
allows you to draw boundaries between
systems so that they're elegant they
have interfaces
and the ways in which these two
different systems or n number of systems
interact with each other
is formalized through an interface so
that's kind of a big kind of takeaway
that he kind of repeats throughout the
book
there's also this talk on entities and
policy
and your entities are kind of the core
domain object the core business object
that your kind of space
is working with and a lot of the
business rules are kind of encoded into
your domain objects
then he talks about different layers the
one above that is called the policy
layer and the policy is the thing that
basically in an application is usually
like the manager class where
a lot of the logic actually takes place
like what to do what and when
and so he talks a lot about the
different layers of an application how
you can build it out
but i guess the question at the end of
the day is should you even buy this book
and my recommendation is yes and here's
why first of all it's an easy read it's
not too
deep it's not too thorough it's
something you can read before bed and
still get it without having your brain
to be in like hyper overdrive mode
second of all it teaches you a lot about
the principles that i wish i knew before
i entered the software industry a lot of
this stuff is basic but seeing how he
applies it to real life examples is
invaluable
and like i said at the beginning of this
video a lot of the concepts that you
learn in this book i actually apply in
real life pretty regularly so that just
goes to show you how useful it is from a
professional perspective like this stuff
makes sense and it's useful
overall i would say just buy this book
it's good to have to learn some of the
basic concepts and even if you already
know some of these concepts it's good to
get a refresher from time to time
and this book puts it out in a very
convenient easy to digest way
and if you're a beginner this is going
to teach you a lot of the basic concepts
that
people like me wish they knew about
before you know they got into the
industry
so there it is i'll put a link to this
book down below on amazon if you want to
pick it up and as always if you enjoyed
this video please don't forget to like
it subscribe it really helps me with the
channel
thanks so much and i'll see you next time