---
title: 'Clean Architecture Example & Breakdown - Do I use it?'
source: 'https://youtube.com/watch?v=Ys_W6MyWOCw'
video_id: 'Ys_W6MyWOCw'
date: 2026-06-30
duration_sec: 924
---

# Clean Architecture Example & Breakdown - Do I use it?

> Source: [Clean Architecture Example & Breakdown - Do I use it?](https://youtube.com/watch?v=Ys_W6MyWOCw)

## Summary

Derek Martin from codopinion.com shares his nuanced view on Clean Architecture templates. He explains the core principle of dependency inversion (dependencies pointing inwards) and then critically examines Jason Taylor's popular C# clean architecture template. Derek argues that while the architecture has merit for complex, large applications, templates often lead developers to over-engineer simple apps and miss the real purpose of a rich domain layer.

### Key Points

- **Clean Architecture Core Concept** [00:00] — The core is the domain (business rules), surrounded by use cases (application), then controllers/gateways, and finally external frameworks. The key rule is dependencies point inwards; outer layers can reference inner layers, but not vice-versa.
- **Template Critique: Domain Project has no Business Rules** [01:56] — In Jason Taylor's template, the Domain project contains only entity framework entities (ToDoItem, ToDoList) with no behavior. Derek expects the domain to hold business rules, but the simple 'to-do' example fails to illustrate this important aspect.
- **Leaky Abstraction with Entity Framework** [06:52] — The Application project defines an interface 'IApplicationDbContext' but it uses Entity Framework's DbSet types, creating a leaky abstraction. This couples the application layer to EF, contradicting the goal of persistence ignorance.
- **Low Cohesion via Layered Separation** [09:42] — The template separates controllers, commands, and handlers into different projects based on layers. Derek prefers feature-based organization where related code (controller, command, handler, validator) lives together in one file/folder.
- **Preference for Feature Slices Over Layers** [11:30] — Derek demonstrates consolidating the four projects into two (Web UI + Features). He argues that physical project boundaries are only valuable when you need a hard dependency barrier. For simpler apps, keeping things together improves cohesion and navigability.

### Conclusion

Derek concludes that Clean Architecture is a tool, not a rule. He values physical boundaries for complex domains but prefers feature-based organization for simpler applications. The key is understanding your context and not blindly following templates.

## Transcript

hey everybody it's derek martin from
codopinion.com a lot of people have
asked me directly or indirectly about
the clean architecture in my opinion
some people have asked me directly and
pointed out to jason taylor's c-sharp
template while others have asked me
indirectly because of the code samples
that i have in some of my other videos
where i don't apply it so here's my
opinion and thoughts on clean
architecture templates where i see the
value and where i don't so let's cover
the clean architecture really quick and
just describe this diagram which you've
probably seen this is from robert
martin's blog in 2012. the very middle
is essentially the core is our domain
this is where our business rules are
outside of that our use cases these are
our application how it's invoking those
actual
domain objects those entities then you
have things like controllers if you're
doing something like mvc or gateways or
presenters for ui but again this is one
step further where this is what's
actually interacting with calling those
use cases and above that is all things
external so if you're generally creating
a web app this is where the web host is
going to live if you're creating a
native ui app this is where that ui
framework lives but the key thing here
are these arrows and these arrows are
really pointing inwards that's why i
have dependencies point inwards because
that's really the key to all of this
is that outside layers can reference
inside layers but inside layers don't
reference outside layers so if you watch
my video on coupling specifically
talking about afferent and efferent
coupling so afrocoupling being who do
you depend on in effort coupling being
who depends on you
is why this is important is because that
the very big at the very center here
with our domain and our entities
who depends on you for afferent coupling
well the use cases does
who do you depend on efferent coupling
nobody nothing is that you don't depend
on anything you have no dependencies
within entities and as you go out that
starts reversing so
a lot of this to me and about clean
architecture is about dependencies and
having that core have no dependencies
things depend on it but it does not
depend on anything else so a lot of
people pointed me to this specific
template this is the c-sharp template
clean architecture by jason taylor so
this is going to what i'm going to use
as my example so this is what the actual
solution looks like there's four
projects application domain
infrastructure and web ui so what that
looks like from the diagram is the
outside here web ui is asp.net core
it references infrastructure and
application
infrastructure is the project that
contains like the db context for nad
framework and any implementations of any
services
the application is handlers in commands
and queries that's using mediator
and then it is referencing the domain
and the domain is our entity framework
entities so first let's talk about
templates for a little bit because i
have a love hate relationship with
templates and because it falls into the
only issues i have with my own code
which is providing examples that are
simple that people can understand and
hopefully the concepts behind it so that
they just don't run away with it and
keep doing the same thing that they
understand their context to see if it
actually fits
that's the problem i have with templates
is that this is a to do list kind of to
do item
sample that it's using to illustrate
this which is super simplistic and
exactly i understand this is a template
it's an example that's why it is simple
but the problem is again people going
with this and running wild with this
when if you're creating a
a smaller type of application do i think
you need to do clean architecture no
i'll explain why more shortly but i
don't think you need to so depending on
the size of your app i think there's
benefits um to the clean architecture
i also think there's a time and a place
for it depending on the complexity and
the size of your app so what i'm gonna
do is go through this template and i'm
not criticizing the template so much as
i am just trying to explain what i think
actually belongs in each project if you
have that project again it's this is a
template it's a sample so i don't expect
it to have a ton of complexity to
illustrate really the nuance of why you
want clean architecture so the first
thing i looked at when i opened this
project was this domain project and this
is the very center of the core it has no
dependencies so it preferences no other
projects and when i was looking at it i
wanted to see what the if there was if
it was doing some aggregates if it had
entities whatever the case may be
and ultimately what it was is it has
this to do item and to-do list
which basically are our entity framework
entities there's basically no behavior
on here at all why would you expect
there to be any it's a to do
but that's the part where it gets lost
is again if people are using this as a
template they think oh this is where my
entity framework entities go and while
it's true that you can have your entity
framework entities live in the domain
project you can have the infrastructure
project which i'll show here has the db
context the entity framework db context
and it's referencing it and it's using
them
i would expect my domain project to
actually have business rules and again
this is a simple example so there are no
business rules but my domain project is
the core of what my application is it
should be the one containing all the
business rules this example template
displays none of that it illustrates
none of that
so if you weren't aware of that's the
point of the domain in your entities and
if you're creating something like
aggregates that are consistency boundary
check out my video on that
that's where this would live but just
looking at this template you wouldn't
know that all right so the next thing to
look at is the application project so
this is the one that's referencing the
domain so it's a layer above the domain
so the things that it has in it that are
somewhat interesting i guess in what i
like about having kind of this
application layer is it's the one that's
actually going to invoke and call stuff
within your domain so
there's this to do items folder and to
to-do list folder and it has everything
separated for commands queries and event
handlers
now i'll talk a little bit more about
this technical separation later on how i
prefer it but i do overall like this
approach
as you maybe have seen in some of my
other videos but one thing i really find
interesting is that the application uh
this particular project is going to
define interfaces just interfaces not
the implementation for things that it
needs one of those things it needs as
you can expect is a
entity framework context
so instead of referencing the actual db
context that's being used directly
rather what it interacts with and uses
is this eye application db context so
the reason why i find this interesting
and why i don't generally follow this
approach is because of a leaky
abstraction
and this is showing it whether you
realize it or not yet right now so
the infrastructure project is what
implements all the interfaces defined in
the application
uh the application project so if i look
at infrastructure i go down there is a
persistence and application db context
so here's our actual entity framework
uh db context that we're using
and it implements that interface
so when i look at that interface the
idea here on the application is it is
kind of lost on persistence it doesn't
really know how it does it doesn't
necessarily know that it's entity
framework right we just have these lists
well actually it does know it's entity
framework because it's using these db
sets and these db sets are directly
coming from entity framework
actually this application project has a
reference to entity framework so i'll
ask you the question if you're going to
have a leaky abstraction or you try to
want to ignore what your persistence is
you're not really doing it with this
approach especially how this is anyways
so you may be screaming well use the
repository pattern i'll save that for
another video because that's a whole
different topic so i'm all for
abstractions the right abstractions and
most times i think external services i
think are really good to abstract
because you can kind of narrow the focus
of what that abstraction does and what
you need it for but when you're doing
something like entity framework or data
persistence i think you lose a lot and i
generally don't think you actually need
it i say that because if you're creating
small applications like this or smaller
little components which i'll talk about
in a minute
you don't actually need the abstraction
because the actual cost of rewriting
where that data access is is so low it
wouldn't really even matter you don't
even need the abstraction
and secondly if you're gonna actually
create an abstraction
what are you losing by using the direct
client or sdk that you're interacting
with if you don't have a really narrow
focus and you need to use a lot of it
then you're just trading more and more
into your abstraction to fit it
if it's something really critical to you
just use it there are exceptions to the
rule i mentioned this in other videos
messaging libraries give you a lot of
functionality that you otherwise
wouldn't get from the client or sdk
directly that you have to implement
yourself so those are the type of
distractions that you do want but you're
not creating them you don't own them
you're using messaging libraries for
this all right so the last project to
look at is the web ui project so this is
the very outer edge this is asp.net core
and we have some controllers in here as
you might expect so let me jump into the
to do items controller
and you can see that it has some various
actions for kind of crud related things
um that we need to interact with for our
to-do item now the reason why i don't
actually like controllers in general is
because they have really low cohesion
and especially even more is that um all
these particular commands here this
create create to do item command
this is exactly a one-to-one like this
particular action in this controller
maps directly to the command and command
handler this is the only place at all in
solution besides tess
that this is actually ever created
there's no other place that's creating a
to do item there's no other place that's
invoking it anywhere calling send on it
it's simply here so the reason why i
don't like this is because i much prefer
having things close together i don't
want to have to jump through projects
and files i would much rather see
everything that belongs together is
together and i can go into one location
and look at basically everything so when
i say group things together i'm
generally less concerned about layers
for an entire application and more
thinking about features and
functionality
and kind of the concerns within that
feature so i'm less concerned about
abstractions and i'm more concerned
about just what a feature does and
letting it define its dependencies and
whether it needs an abstraction or not
so instead of thinking about the whole
layers i'm thinking about what's a
particular subset of features and let's
pull out the important parts and put all
that stuff together so well instead what
it really looks like is maybe i have two
web ui pieces which are really the
controllers that's interacting with say
the same infrastructure which maybe
could be the certain db context which
interacts with our app which is our
mediator commands or queries and
handlers and maybe those two particular
features share a domain but i'm
organizing code that way i'm not
organizing code necessarily by layers
that's happening in that template so
taking that concept and consolidating it
what this means is i have two projects
now not four
i have the outermost which is the web ui
which is asp.net core and i have to
define this as kind of the entry point
this could be asp.net core this could be
a
native ui this could be like a service
that's interacting with your your
message broker that's going to be
invoking into your application this is
kind of topmost entry points but i don't
actually have any of the controllers
here
really the controllers are living in
their respective features so i now have
a folder called features and i have
these to-do list items and
lists and items
and instead of having a file for
basically commands and queries like it
was earlier and event handlers i left
the event handlers in here because they
don't really do anything normally these
would actually just be a part of this
name to what they actually do
but if i jump into the create to do item
here it has the controller here the web
ui is referencing this it's
automatically going to pick up this
controller i have the relevant mediator
command
the validator for it and the relevant
command handler
since it's publishing an event i
actually have the event here as well so
when i'm talking about or thinking about
anything to do with an actual command
everything resides in one file it's one
place now often the argument is well now
you're referencing asp.net core in this
application project but it really only
needs to be in the web ui true that is
true however
if you do create some other service if
you do
that doesn't need asp.net core well yes
you will still be referencing it and it
just won't do anything that's a price
i'm willing to pay to have code that
belongs together live together so that i
can access it directly and understand
instead of jumping through projects and
layers i have things closer together so
you'll notice i took out that domain
project and the reason is is because
there was nothing meaningful in it if i
was creating a rich domain i did have a
lot of complexity around my domain and i
wanted to create a separate project so i
didn't have any other dependencies that
i could focus specifically on that
domain to create entities values objects
aggregates then yeah that'd be a great
idea in this example for illustration
purposes there wasn't anything
meaningful in it so therefore what's the
value of having that project so the
value to me in separating by project is
if you want a hard physical boundary
with dependencies an example of this is
that you don't want to accidentally put
say some type from asp.net core in a
mediator command or query because if you
do need to rip that out well now you are
actually bound to asp.net core because
you have that reference in there in the
original template you wouldn't be able
to do that so again yes it is about
context it is understanding what you're
doing and what types you're using where
if you want to accomplish that by having
the boundaries of projects and layers
excellent that more power to you
if you can see past that and you
actually want to create slices where
you're depending less on abstractions
and creating smaller units where you can
refactor those and pull those out
separately then to me there's less of a
concern about those abstractions because
if you need to replace them what the
actual underlying implementation is with
something else you can do it so for
everybody that's been asking me about
this i hope it helps if you found this
video helpful give it a thumbs up if you
have any thoughts or questions make sure
to leave a comment and please subscribe
for more videos on software architecture
and design thanks
you