I spent a ton of time following clean architecture like religion and always found its structure needlessly complex. I eventually found myself doing what's implemented in this video and never looked back. Thank you!
Following ANYTHING like religion tends to be an error in my experience. Guidelines and best practices are not replacements for applying real engineering principles to a problem.
There are times when it’s a good idea to use clean architecture. Basically, any time you have well defined system needs boundaries, and a lot of such subsystems, clean architecture becomes really nice. If you’re writing something that’s relatively small, then no, you won’t get much benefit. Or if it’s something highly specialized that won’t be reused, clean architecture probably won’t benefit those sorts of system either.
As soon as I discovered your channel, I had to look for this video. Nothing frustrates me more than people blindly following whatever pattern is trending. Thanks for covering this topic.
The problem, as I see it, is people just don't know "what" to do in terms of structure, so the lean on a template or something from a tutorial. The issue there is that it's not often described WHY a pattern/concept exists and what problem it solves.
Thanks for challenging and confirming my ideas on this. I commented the same to Jason re the EF dependency. One reason for the more hardcore clean approach that I don't see mentioned is that in the same way that correct use of access modifiers "documents" the code, so does it's dependencies. For this and all the other reasons, having to update an endpoint in one project and handler in another is worth not declaring that aspnetcore dependency in the project with the handler. But I appreciate your unbiased handling of the topic and respect your preference. Also I think it's worth calling out that all the "outside" dependencies shouldn't live in a single project. I'd argue that orchestration between two third-party dependencies is business logic and should be against interfaces in the application layer. Keeping the implementation of those interfaces isolated enforces that (and encourages code that's more SRP).
Agree, a lot of this is variable depending on your context. As others have commented, having the project boundary prevents someone from doing something they can't. Which I'm all for. But as I've also mentioned, I prefer smaller units of functionality. Because of that, I'm not worried as much about taking a hard dependency and not abstracting it. In .NET land we can enforce these boundaries by projects, however there's no reason you can't do it exactly as I consolidated to. It's still following the direction of dependencies, just not by separate projects. Appreciate the comment!
Finally I found a reasonable explanation. Everyone just trying to make us memorize Clean Arch. But no one tells what if I don't need CQRS or something like that?
Personal opinion. There're a lot of book writers, conference speakers, "consultants" etc who dream to come to you with new shiny architecture which will solve all your problems and bring your product to success (not for free of course). Some of them are balanced, while others force engineers to stop using the _common sense_ and follow dozens of rules just to make it work. That's why we have some approaches where to get 2+2 engineers have to write 300 lines of code to integrate with some framework and guarantee all "principles" are met. Following rules even when you know they're wrong leads to bad quality and slow development.
Agree. The problem as I see it is using patterns as a prescription. If you use it when you don't have the problem it can add complexity. But when you do or start having the problem you need to be aware of it and take action. Context is king. 👑
I really like your opinion. I've been working on a huge platform and the code got bigger than what I expected and I started looking for ways to improve my architure. This makes me feel better because I felt bad using my formal architecture for small projects but as you say it’s just fine. But for this big app I’m talking about I really need a strict separation of layers because later we will be moving to microservices and we really need code that can be easily broken into smaller pieces.
I was the one screaming use repositories : )) I think somewhere in the git repo history you can see the full evolution of the template which had repositories as some point. And that's how I still use it in my projects. Great topic and great video. 👍
@@CodeOpinion Have you put a video out for this yet? You mentioned one in the video I think. I'd be very interested in that. I use repositories but only because I don't really know what other pattern to use... though maybe that's cause I just apply the term repository to anything that accesses data from the outside world.
This is a great video. I've been experimenting with clean architecture lately but have never gotten a straight forward example of what it looks like. My current style of implementing it is based off my interpretations of snippets from other posts. What you've described is pretty darn close to how I implement it which is very encouraging and shows me that I'm not just crazy. The grouping of all the pieces in a single file is interesting to me. I can see how, for smaller projects it might be OK but even that small example you had made that file enormous which might be unwieldy. I definitely think for a larger project, it might be worth it to use a folder for each feature and put each class in it's own file so as to have smaller, more manageable files. Though I definitely see how that can lead to times where you're flipping back and fourth between lots of files when you're working with the whole stack
First Clean Architecture talk I've seen/read online that acknowledges the difference between Afferent and Efferent coupling, rather than just saying "NO CODE DEPENDENCIES!"
In the clean and onion architecture (aka hexagonal, akaports and adapters architecture) the idea is that Infrastructure is decoupled from Application and the consumer (Web) is responsible to plug in the concrete implementations of Infrastructure at runtime. The interfaces(contract) of the Infrastructure is usually stored inside the Core project. That leaves us the freedom to switch any time the Infrastructure implementation to another concrete implementation depending on the situation/providers and so on.
Thanks for the comment. While that's true conceptually about using different implementations and just depending on an interface, I don't think many people actually do that in practice beyond testing scenarios. And if you do, I'd argue that swapping implementations isn't straight forward if you have unknowingly leaky abstraction. I'd argue it's more about coupling as I mentioned in the video. As I mentioned, I'm more concerned about keeping small units (groups) of functionality (vertical slice) that define their dependencies and decide if they need abstractions on them. If you do, great, full steam ahead with Clean/Onion/Direction of Dependencies. If your slices are small, "freedom to switch any time" is a matter of changing the dependency, which isn't a nightmare if you're units are small. Again, I appreciate you taking the time to comment! Thanks!
I see your point and I admit it is fair enough. I also see that some type of Infrastructure components it is better to be plugged in at the consumer startup or even switched dynamically on runtime based on some other criteria. Example of components we want to be generic and be switched: - email sender provider - data storage (even databases, caches, entity framework) - other external service providers we want to "adapt" for our system.
Wow, finally someone giving a proper analysis to the Clean Architecture. Agree 100% on that Dbset dependency issue and also there's another one that I still didn't find resolved anywhere and that is the isolation of Identity. Having my own User class, how to isolate the domain objects used by Identity without referencing the library? Great video. Would love to see your approach and a concrete example of your solution to my questions.
The core would have a User concept, and then the domain/UI layer would wrap that class. Not sure why this is a problem? Maybe I’m not fully understanding your question.
Let me think it aloud here, Is a user class central to your domain or is it a concern of AuthZ and AuthN. If the User class is your central concern, both the identity server and inbuild identity prodivder let you to configure things in appropriate places i.e. User object can be extended in domain layer and configured in infrastructure layer and the packages do provide such granularity. If the User is not your central concern and it is only for AuthZ and AuthN (and related uer profile data) the defaults would do right?
Your videos are awesome!!! Thank you for the amazing real world approach to all things C#!! You take a real world approach which is very helpful compared to 99% of others which take a “proof of concept” approach. Please keep it up! Been watching your videos all night
I feel both strategies work well together. Package by feature and then package using Clean Architecture within those features. However, my C# is very rusty so not sure it's applicable. But great video none the less. I wouldn't couple UI to the domain though. When the client decides that the UI needs to aggregate results from a middleware abstraction, you end up doing more work. But each project is different and doesn't necessarily fall into the same scope.
Really helped out a ton! Currently using this architecture as well, but been eyeing on the loosely coupled monolith example you made before as it seems a lot easier to take out parts and put it into microservices if it becomes a requirement. As well as the code that should be together, should live together argument.
I simply prefer to think vertically (loosely coupled monolith) rather than horizontally. With narrow vertical slices, abstractions and layers matter less in my opinion. They are still important and so are abstractions, but the concern is less because being coupled to anything you down own has less of an impact if it needs to be removed. Also focus on capabilities rather than technical concerns is a giant win to get out of a CRUD approach where it matters.
@@CodeOpinion thanks! would you recommend a loosely coupled monolith for a LoB app for insurance brokers? It's a very data centric business, but part of it does a lot of things with the data. Would really get into DDD with it but having a hard time splitting those entities out as it seems impossible in my scenario.
@@CodeOpinion I think there is some confusion on how Vertical Slices approach presented here compares with the Loosely Coupled Monolith in your other video. If they are in fact the same, it would be nice if you could clarify how you implement a local Message Broker inside this vertically sliced loosely coupled monolith.
Layers and interfaces definitely don’t scale well with complexity. Slices like you described do. Having the flexibility to choose transaction script, domain model or event sourcing on a per slice basis as well as only ever adding code to implement a new slice works great with large apps. Another great video!
Another great video. To be fair, I think Uncle Bob specifically mentioned that architecture is about risk management etc (the "tension diagram" towards the beginning of the book) but more importantly that his 4-layer diagram is an illustrative example; that there could be more or less layers. I think it's tragic that so many "clean architecture" examples shoehorn an application into the 4-layer paradigm. Project triangle for the win. Figure out which corner matters least and choose the path accordingly. Taking the time to make a GOOD abstraction is always a step in the right direction for quality. Understanding project scope and not wasting time on abstractions that will never be relevant is always a step in the right direction for cost and time. Afterthoughts: Deployment matters. For you youngsters: there was a time when software had to work and be close to perfect by the time it went into production. Video games used to be distributed on cartridges and optical discs. Updates were not even a possibility, so abstractions would have been ridiculous outside the context of a reusable video game framework. There are still some systems that operate like that (non-IoT embedded devices etc). Check out the "when to use" section of the GoF Design Patterns book for the "Bridge Pattern" ... if I recall correctly, it says you shouldn't use the Bridge Pattern when there's only going to be one implementation. The Bridge Pattern is basically two layers of Strategy Pattern organized by role and a perfect OG example of a clean 3-layer architecture; Inversion of Control employed to isolate application logic (i.e. the "Abstraction") from the drivers & frameworks layer (i.e. the "Implementation") #UseTheRightTool4TheJob
I don't see that you should do a specific pattern, but live up to the principles as long as they serve your needs - being pragmatic. The rest is just project style. In the beginning I took a "template" and modified that to suite my needs. Now I understand the principles, where that template fails for me, and can do all from scratch - without the template
Would love a follow up video on using IRepository in the application layer and implementing it in the Infrastructure layer with DbContext and Entity Framework as the Data Source
Agree. Various forms with slight differences in definition but ultimately it's about coupling and direction of dependencies (afferent and efferent coupling)
"Clean architecture" sounds more silver bullet solution. Uncle Bob: O, you have a mess of an architecture, just use Clean architecture Dev : ok, thanks, but I don't know how to implemented Uncle Bob: I do, but that will be XXXX dollars / hr
11:02 Seems to sound like an archetecture mentioned by Jimmy Bogard. Vertical Slice Architecture which is basically a Single Slice of Clean Archetecture where all(mostly) code resides
I had the exact same reactions to just about everything you've covered here. I love the architecture, but this template is not great. I think I just lean into abstractions from the very beginning regardless of the size of the project (unless it's super tiny of course) because I have personally found more benefit over time than cost. The greatest cost I've run into over the years is uninitiated developers. I think the way you described the grouping of functionality falls under another uncle bob concept which is 'screaming architecture' and I fully agree with it.
Yeah, exactly. I really appreciate his "screaming architecture" principle. The only thing the "interfaces-controllers-application-domain" grouping tells me is that I'm looking at a clean architecture. I really enjoyed "the Missing Chapter" of that book and it mentioned the pros and cons of a few different ways of organizing code.
MediatR != Clean Architecture Use namespaces for vertical slices (contexts and features). Use projects for horizontal layers. Keep Infrastructure issues separated and limit the visibility of third party dependencies by having more that one Infrastructure project (one for UI, another for persistence, another one for messaging, etc.). If your IDE does not let you see all classes of a given feature (namespace) across all projects, it's the IDE's fault, not Clean Architecture's. YW.
I am a Java developer. To do Clean Architecture, I would prefer creating a multiple module Maven or Gradle project. The interfaces and classes related to the different levels of abstraction, e.g. Domain, Application, Infrastructure, Web are placed in their respective modules and the dependency among the modules are configured with direction pointing toward the center of the Clean Architecture circle. By doing this, you won't mistakenly create a reference to classes or interfaces residing in the outer layers.
In my context, I don't view authorization as a web concern because HTTP is just one of the methods to interact with the application. I need a common authorization if its an coming form ASPNET Core or say a Message Consumer. So it depends on your context.
One thing that makes my head spin about Clean Architecture is that the diagram states that in the green layer you implement your gateway (repository) but a repository is related to a database, which in this diagram... is in the outer blue layer. So if I were to strictly follow it, it's telling me that I would need to create an abstraction between my repository and the database driver/ORM. Same goes for the controller, e.g. according to the diagram my mvc framework needs to live in the blue, but I should also have a controller in the green. What are your thoughts on this?
I tend to always wrap an ORM. Small projects it doesn't matter as much but define small. The reason I wrap those is to remove the dependency from the business layer. The business layer has less reasons to change and you control the interface vs ef core. The business is the most important part and tends to out live all other parts of the application. In a perfect world this is how it would be done within clean architecture, however I have seen more of the opposite. My main argument is that the critical piece has less reason to change and therefore more loosely coupled to the persistence layer. I can think of several reasons as to why it would change and have seen those.
hey, I'm a big fan of you and I like the vertical slices arch you introduced in the video, I have a question, do we still need Mediatr since we can directly write the application logic in the controller action, and we can also use the controller filter just like Mediatr pipelines?
That’s why reference /sample application implementations can be more useful than templates. Templates tell you this is the way you do things no matter what you’re building whereas samples tell you this is one way you can build that type of app. Templates also give you a starting point that makes assumptions that may not be valid for your use case.
That's a good way of explaining the difference. However, I often even have trouble with sample applications because they still don't often explain the reasoning behind the decisions. This actually makes me think sample apps need to include Architecture Decision Record (ADR) in markdown in the repo.
Ha! I've had that comment before. It's so I'm looking in the same direction as the screen when recording. Otherwise I'd be looking in the wrong direction which seems odd.
I was asked this question during job interview came here to know the answer. I'm not really good at definition of terms interview I think I screwed my interview. 😭😅 Thanks you so much for the explanation.
Not sure I agree with the controller being in with the handlers as it's still a 1-1 for the command and controller. So you could just leave that in the UI project and not need to reference NetCore lower down. For me I try to make Infrastructure and Core levels in NetStandard so that I'm not restricted on the entry point projects type Xamirin, NetCore, ML. Love the videos though, keep them coming
Absolutely, if you want to re-use the application layer in another top level (xamarin) where you absolutely do not want to reference aspnetcore. But again, if you aren't doing that or the reference doesn't matter then it's something to consider.
Physical boundaries nudge developers in the right direction. They create a path of success. If however, a dev really goes out of his way to get his feature working by crossing these physical boundaries then it would be pretty evident for a code reviewer. The bigger the team and the rate of incoming commits the more important this becomes.
I wouldn't say that, think it's just a decision they made since they didn't want to introduce a repository, since a EF Cores DbSet is one. But then you leak that dependency and it has implications of knowing when it actually materializes and makes database calls.
I quite like the idea of putting command handlers in the same file/space as the controller that calls it. Our complex domain aggregates tend to have many different ways they can be mutated, so the file would be thousands of lines long. Also our domain gets called by a lightweight CLI/Service that shouldn't have any knowledge of ASP.NET core. So that's one reason not to. For this app, I do like your arrangement. We still group things together by aggregate. As we evolve our structure (we're porting currently from old skool 3-layer MVC->BLL->Database to Brighter/Darker Command/Query) then there's plenty of opportunity to structure along the way. Food for thought, thank you. One feature I'd love in C# is a namespace-level accessor. Like private/public/internal, called 'spaced' where that type is only accessible to its namespace and the namespace children. It would allow me to form boundaries between aggregates that can be caught at design time. When I do my Unity game dev hobby stuff, I structure my projects very differently to the accepted wisdom. I group by feature - just like you recommend.
I also have services that invoke commands via message dispatcher that leverages the same code. The reason that ASPNETCore dependency is not a concern is because some of these message consumers generate emails which we leverage ASPNETCore & Razor.
@@CodeOpinion ah ha! I did wonder. That makes sense. We use Razer the same way! For the moment we've also got that reference in our domain for the same reason but I'd prefer it to be an event handler, dispatched after the command so that failed sends can be dealt with polly. That's for the future! Thanks for the insight!
I see this template as a good learning tool, in that it highlights some of the code structure issues faced by non-trivial projects that people will encounter. One of the key points to bear in mind is it is supposed to give a structure within a team environment, where multiple developers are adding features over time, and a well known standard has to be applied for various features and bug fixes, maintenance work etc. as team members come and go. I can see value there, in formalizing an approach that has wide industry awareness. It could also be appropriate when attempting to modernise a brownfield project, giving a target structure for gradual migration. But, I personally don't see it as my default *starting point* for an application; I don't begin with layers or abstractions, I refactor to abstractions or patterns as and when they are useful. So from my personal preference, I do create templates for Unit and Integration Tests. Then I follow a lightweight TDD / BDD approach for use cases, which drives my domain model and the relationship between components. When that has reached a stage where the overall domain is apparent (even if not complete and will of course still evolve), I can then look at structure, and how best to deploy it. That might be an approach similar to Clean Architecture deployed to a web server, or it might be a fine-grained Functions based approached, containers etc. there are of course multiple factors to bear in mind. That then guides me in how far to go in creating the abstractions / layers etc. - we've already covered testability by following TDD, and when the deployment model is determined, we can start creating integration tests. Typically I use Visual Studio Snippets / Rider Live Templates, rather than full solution templates. It gives a nice combination of common approaches to implementing patterns, without specifying that they must be implemented whether or not they add value in the specific context of the application. Oh, and repositories are a useful tool - not everything within a repository has to be a database accessed via EF. Dapper, storage, queues, etc. I always find it amusing that the people who are so definite regarding repositories as redundant due to EF, are often some of the biggest detractors of EF, and would dump it in a heartbeat if an when something better comes along.
I also use Rider Live templates for single files. I'm not for or against repositories as a global statement. It really depends for me. I often see them used where I would not though.
I think what you're looking for is to have a package by bounded context (or feature - although feature is even smaller), then inside of it to have have DDD for that bounded context and hexagonal architecture. This way you have high cohesion. What do you think?
When you say "package" I'm assuming you mean some unit that you can reference from other "packages". In the sense of a package manager and dependencies. While you can use this approach for separation, you don't have to. Ultimately it goes down to "logical" decoupling. How you want to handle the physical aspect is a separate concern.
@@CodeOpinion yes, it's a logical separation. But as you said, if you want to grab a functional piece of your system and put it elesewhere, having each piece under its folder (with its domain and infra) allows that. Another thing, I know the separation is logical, but the high cohision part is related to folder, isn't it?
I've been reading the book "Clean Architecture" by Uncle Bob and I think this "Clean Architecture" template project looks more like a typical DDD project. I am confused now. So what is the difference between DDD and "Clean Architecture"?
I've looked at various implementations and all are slightly different in naming and exactly which technical concern in is each. However the goal is direction of dependencies and coupling.
I'd argue that the focus of each term is different. In essence, they are not two conflicting ideas. You can absolutely have both. "Clean Architecture" is more focused on decoupling different pieces so that they are swappable in the future. DDD, on the other hand, is more about a mindset of understanding your domain, including the language/term people use and the domain constraint (business logic), e.g. a locked discussion thread should not accept new posts, etc. Such logic should be mapped out in the domain layer. Otherwise, the domain entities become what's called anemic models. Subsequently, service/application layers get thick, which leads to a very procedural style of implementation.
A simple rule of thumb for designing DDD approach is never think about database, table's, ui etc. Focus on domain object and it's behaviour. Incorporating DDD in clean architecture is where we get lot of questions like which layer to place each stuff. After reading many articles on internet, it would put us on confusion. Example: few justify repository interfaces should live in domain layer. Few say it should be in Application layer. Few say avoid factories for creating domain instances. But practically I see factories are very useful in creating domain instances. Few say don't use factories and use builder. It would be great if software community creates a sample project to showcase how it should be done correctly with justifications. I am glad I learnt certain standards and practices to follow from microsoft eshoponcontainers project. But not getting certain answers from the software community like: how to achieve event sourcing and publish integration event to event bus while using microsoft asp.net identity? Is there any portal where all of the if's and why's are answered with justifications?
If I understand correct, App layer keeps abstractions, DbContext and does everything. Infrastructure layer does implementation of App layer, Any UI can have reference of infrastructure layer and consume App layer. Domain Layer keeps only entities....? If so, Seems App layer should be closest layer to UI.. (while UI using MediatR services there ). Would it be a choice to carry abstraction(interfaces) to domain layer , implementation and DBContext to infrastructure. App layer will have all others and reference of infrastructure. UI has reference of app layer. ???
Purpose of the domain project is to silo your core domain (object model) into a project with no references. The reason for the no references is to eliminate any efferent coupling in the domain project. You can ultimately structure however you want, but the purpose of this is really to reduce coupling.
the point is to get folks start with something mean to become bigger thing. when you bake the controller into the application you cannot reuse this project for a console application. the point to separating projects is that you can put any new UI technologies on top of the application project.
Sure, if you are going to be a new UI tech on top. If you do, by all means separate out the controllers if that's what you want. Having said that, the controllers won't stop you from adding WinForms. It's just dead code.
Great video and analysis of this template. Although I will note that the criticisms you raised are actually addressed in Jason’s talks and documentation. They’re not arbitrary choices or glossed over, they’re deliberate choices that he explains. Also early on you make a comment about this being a template and then go on to say it shows a simple example and it’s not suitable for something this simplistic - Jason also emphasises this himself.
Thanks for the comment. It wasn't intended to be criticism of the template, him, or clean architecture. My intention was to explain the value in which context to apply clean architecture. Unfortunately I watched his talk after I record this video (someone posted it to me where at the end he talks about it)
Thanks for this great video, very useful and abstract :) It is encouraged to make a video about the abstraction of ef core context or the design that should abstract the access to the database in this architecture, with some other than ef. Keep going! Thanks, again! +1
It's funny to see that "clean" architecture leaks the abstraction of specific framewrok (EF) into the contracts therefore forcing one side tto expect the other to be using the EF. To me this is really a smell that the author of this repo doesn't really understand what intertfaces are for. I would like to see him swapping the EF with MongoDb Driver without breaking this DbSet-based contract
I don't disagree, however it is an example. The reason being, my guess, is because he did not want to add a repository. Because of this, the DbSet must be there in order for change tracking to work with EF.
@@CodeOpinion Well, CRUD based repo is a strange idea itself to me and it would be better to have FirstClass abstractions that execute specific business rules rather than exposing the direct reference to db collections 😅 Of course, one can argue that this is just an example, but this is specific place with interface containing DbSet is literally an example of how not to do it 😅
Adding an abstraction is not just about swapping the ORM. The main value of abstraction is that you will have a single place for all calls to db and it gives great flexibility. Just imagine that at some moment you will need to mark entities as deleted instead of physically deleting them. If you have abstraction you will do it easily in a single place
Hi , thanks for taking out time to explain in detail. I've always wondered if CA was any use in small projects. Do you by chance have a repo to the approach mentioned in the video, something in the line of a sample project that demostrates the use?
All of the code samples I made are available to Patreon on UA-cam Developer members. Check out the links in the description of the video for info. As well as the link for the original template which is on GitHub.
Hi, Thanks for your helpful video. What do you do for abstracting EF Core context without leaking abstraction? Here we used DbSet in the Application layer, and it is leak of infrastructure in the application layer. What is the solution to this problem?
I have done an abstraction of EF without leaks. So now I have my own adapter for dbcontext. Dbcontext it is already repository so I am avoiding creating some new repository. I just created my own dbcontext which is just adapter for EF dbcontext
@@CodeOpinion It's a way to structure code. It was introduced in the book Object-Oriented Software Engineering: A Use Case Driven Approach by Ivar Jacobson
What you're saying makes a lot of sense. But isn't the reason for the IApplicationDbContext interface so that the Application layer can use the DbContext features without explicitly depending on the Infrastructure (outside) layer? i.e. Inverting the dependencies. I agree it sort of falls apart when the Application project references Microsoft.EntityFrameworkCore, among other things. I've seen some Hexagonal Architecture examples in Java but am new to Clean Architecture in .Net. It all sounds good on paper, but virtually every .Net repo I've seen so far has violated the principles in some way, at least as I understand the purpose of each layer, which I may be mistaken.
Yup. It's just that interface exposes the dbset which defeats the purpose IMO. Because of that you have to have knowledge of when a interaction with it actually makes (materializes) a call to the DB. It's leaking that.
How to "really" do it depends on your context. The template is a good example in itself and it will likely fit many use-cases. I prefer a bit of a different approach because I prefer smaller units of functionality which lets me determine each units dependencies. By doing so, I can choose to use the dependency without worrying too much about creating abstractions.
Can you please make a video explaining the Modular Monolith project template in detail? Github -> kgrzybek's 'modular-monolith-with-ddd' repository. Thank you!
Overall video was helpful. Appreciate! But your verticle slice implementation is breaking a fundamental rule of Clean architecture. In CA, the dependency should point inwards and not outwards! When you put controllers in Application layer, now presentation layer need to reference Application layer (ideally it should be other way around) to register those controllers to web host! And also all related things for each domain are in one folder, so I think it's already better to discover those things. Controllers are outside in other project, because that is presentation layer and there might be multiple presentation layer in real world using same application layer!
Yes, if you prescribe to clean architecture. I generally don't as I'm more concerned about small units with high functional cohesion. Because their low footprint, I'm not as concerned with layers or abstractions.
I'll do it eventually. It seems to be a absurdly divided topic which is hilarious to me. There are people that are in favor of it and people that aren't and nobody in the middle.
In the project I’m currently working we are doing ddd and I can “accept” the need of the repository pattern in some entities but I can’t see the need of unit of work as my dbcontext does that for me… but I’m just a junior dev trying to understand big guys worries here! I will be checking in for that video! Thank you!
Interesting approach with controller in same file. What if the controller has more actionmethods? Which is quite common. Do you make it partial and split it up?
I suggest you read the book Clean Architecture and then tell us your opinion. One probably shouldn't judge something when they haven't even read about it from the original source. This template doesn't demonstrate the Clean Architecture.
Curious, what about this video did you disagree with? That I didn't correctly explain what clean architecture is? Or that I used a template that didn't follow it. I did explain that the template didn't follow it. I also hope I was explaining the value in Clean Architecture is about direction of dependencies and ultimate as usual about coupling.
You cannot call this template Clean Architecture if it violates most of the dependency rules. These interfaces also seem to live in wrong place, these gateways and interfaces should be part of the domain/core. Todo is worst example to display on Clean Architecture anyway, no business rules at all in core as you mentioned.
Like I said, templates and examples are difficult because they need to be simple enough to explain, yet not complex enough that all is lost. However, simple examples tend to lead people down the wrong road if they don't understand the full context. It's difficult and I struggle with it in my own code examples.
Why gateways / repositories should be part of the domain layer? Genuinely curious, as they're objects that should not be used in domain layer but in application layer - we can call them adapters if you want hexagonal-ish terms. Besides, typically you try to reach domain purity working with in-memory objects, not out of process dependencies.
@@iorch82 I meant only the interfaces. Your core should never know where the data comes or where ot goes to. In Clean Architecture diagram they are same as input and output port interfaces. You put them together with your core domain, because they are USED by core and IMPLEMENTED by adapters. This allows you to test your aggregate/core/domain using nice simple mocks by implementing these small interfaces (usually one method inside them or functional interfaces) in-memory.
As I mentioned in the video, I'm fine with ditching abstractions and going "all-in" if you think it's worth it for your situation. However, if you are, then don't bother trying to create your own abstraction on top and lose all the functionality of it.
@@CodeOpinion There is also an advantage in selectively choosing what to abstract. If there is no expected future pain, or abstraction doesn't solve it all anyway (eg. relations with EF vs. event store), and the abstraction cost is high, then I wire it in. If, however, the abstraction cost is low, the current implementation is a commodity (eg. a CSV library), future pain expectable, then I abstract it away in a separate project.
to me clean documentation is better than clean architecture. also when it comes to abstraction 2 -3 levels is enough and it must go down the folder not bouce around
Idk, have seen this template over the years, seems overly bloated for small/medium projects. Repository pattern is stupid for EF Core. Having 100 layers to use Newtonsoft.json is also dumb, you are never going to change it. It's not a library from a random guy that may get removed/dropped. Also the template uses a mix of razor + any frontend library , uses razor for auth. Don´t understand WHY would you mix your API with a Partial HTML response ever. Like the idea of this, but overuse of abstractions and interfaces is just annoying. If your db has 10 models and 5 controllers, it does not make sense to have 25 Dtos, 10 repositories, and 50 abstractions with 5 layers of services calling each other. You end up using more time to code all this and do not even start about the tests for each thing here.
Coupling? Not really a fancy or new term. Probably the thing least understood that is the cause of most of the complexity written in software in my opinion.
For more complex Projects why just not split verticaly, but add projects as layers too? Yes a lot of solution folders and projects, but much harder to make mistakes. I would like to work for models, handlers, validations, events from the same file… but you need much more discipline and for every team member to actually understand the problem.
I find most developers work based on the existing structure. They mimic/replicate what's already there. If you are organizing a certain way, most folks will follow the same standard.
@@CodeOpinion yes for common problems... but then something more complex will come up, and one developer will make a shorcut, and then the other one... and you will have chaos...
No. Just no. Where is it clean exactly? There's so much noise and unnecessary interfaces and classes. It's crazy! An architecture is clean when you know where to find stuff. Here, you're completely lost. It too much!
This sadly is a bad example of clean architecture which is why you don’t need to or should use it. I’m typing with one finger otherwise I’d happily go into why 😛
All good n' all but: Opinions will be opinions. I get that people find some approach more useful than others, I get some ppl get "married" to certain technology or platform, all that is OK. The onl... ERASE Entity Framework!! NOW! incarcerate the maniac that came up with it, melt the key and pour salty water in the door lock! Besides it takes a lot of extra time with no added gain, and makes the boilerplate a horrible broken-rows mess. Who in his/her sane mind will prepare a whole application to be, not only DB agnostic (which I adhere, of course) but "automatically" deployable.... what comes next: auto-migration? What the million other approaches to persistence out there? are SQL based a must? I get people have to find some work to do at Microsoft these days, but c'mon! do something useful, like that time when you did MS Messenger, or BizTalk in the early 2000s, or SOAP and webservices... at least seamed that you cared... Be a professional: manage your entities! (Rant is over)
I disagree that the point of the domain layer is to have business rules. The domain layer is simply your core models, no logic. The application layer holds all the logic, in this pattern, the queries and commands. And I think that is a very clean separation
If you don't have any behavior or logic on your "models" then I'd call those data models, not domain models. If you're relegating your business logic in some type of application layer, then you're using what most would call a transaction script.
Sorry, what? Where did you learn DDD from, Twitter? The book defines domain layer as: [[Domain Layer]] That portion of the design and implementation responsible for domain logic within a LAYERED ARCHITECTURE. The domain layer is where the software expression of the domain model lives.
I spent a ton of time following clean architecture like religion and always found its structure needlessly complex. I eventually found myself doing what's implemented in this video and never looked back. Thank you!
Following ANYTHING like religion tends to be an error in my experience. Guidelines and best practices are not replacements for applying real engineering principles to a problem.
There are times when it’s a good idea to use clean architecture. Basically, any time you have well defined system needs boundaries, and a lot of such subsystems, clean architecture becomes really nice.
If you’re writing something that’s relatively small, then no, you won’t get much benefit. Or if it’s something highly specialized that won’t be reused, clean architecture probably won’t benefit those sorts of system either.
can you give me your method of how to design and organize code in solo project?
This explanation is really CLEAN. Thank you.
As soon as I discovered your channel, I had to look for this video. Nothing frustrates me more than people blindly following whatever pattern is trending. Thanks for covering this topic.
The problem, as I see it, is people just don't know "what" to do in terms of structure, so the lean on a template or something from a tutorial. The issue there is that it's not often described WHY a pattern/concept exists and what problem it solves.
Today I've watched about 7 videos on your channel, and I really like your ideas and approach because it is practical and rational. Thank you so much!
Glad you like them!
Thanks for challenging and confirming my ideas on this. I commented the same to Jason re the EF dependency.
One reason for the more hardcore clean approach that I don't see mentioned is that in the same way that correct use of access modifiers "documents" the code, so does it's dependencies.
For this and all the other reasons, having to update an endpoint in one project and handler in another is worth not declaring that aspnetcore dependency in the project with the handler. But I appreciate your unbiased handling of the topic and respect your preference.
Also I think it's worth calling out that all the "outside" dependencies shouldn't live in a single project. I'd argue that orchestration between two third-party dependencies is business logic and should be against interfaces in the application layer. Keeping the implementation of those interfaces isolated enforces that (and encourages code that's more SRP).
Agree, a lot of this is variable depending on your context. As others have commented, having the project boundary prevents someone from doing something they can't. Which I'm all for. But as I've also mentioned, I prefer smaller units of functionality. Because of that, I'm not worried as much about taking a hard dependency and not abstracting it. In .NET land we can enforce these boundaries by projects, however there's no reason you can't do it exactly as I consolidated to. It's still following the direction of dependencies, just not by separate projects. Appreciate the comment!
Finally I found a reasonable explanation. Everyone just trying to make us memorize Clean Arch. But no one tells what if I don't need CQRS or something like that?
Personal opinion.
There're a lot of book writers, conference speakers, "consultants" etc who dream to come to you with new shiny architecture which will solve all your problems and bring your product to success (not for free of course). Some of them are balanced, while others force engineers to stop using the _common sense_ and follow dozens of rules just to make it work. That's why we have some approaches where to get 2+2 engineers have to write 300 lines of code to integrate with some framework and guarantee all "principles" are met. Following rules even when you know they're wrong leads to bad quality and slow development.
Agree. The problem as I see it is using patterns as a prescription. If you use it when you don't have the problem it can add complexity. But when you do or start having the problem you need to be aware of it and take action. Context is king. 👑
I find these videos really valuable. Keep going! :)
Glad you like them!
I really like your opinion. I've been working on a huge platform and the code got bigger than what I expected and I started looking for ways to improve my architure.
This makes me feel better because I felt bad using my formal architecture for small projects but as you say it’s just fine.
But for this big app I’m talking about I really need a strict separation of layers because later we will be moving to microservices and we really need code that can be easily broken into smaller pieces.
Yup. Context matters. Being aware of the system evolving as it grows and re-structuring as required.
Exactly what I was going to write. For big projects and big teams boundaries are your friends :)
I was the one screaming use repositories : ))
I think somewhere in the git repo history you can see the full evolution of the template which had repositories as some point. And that's how I still use it in my projects.
Great topic and great video. 👍
Thanks! Repositories are a religious debate and I'm not sure I want to go there.. yet.
Also, thanks for the support. I really do appreciate it.
@@CodeOpinion Have you put a video out for this yet? You mentioned one in the video I think. I'd be very interested in that. I use repositories but only because I don't really know what other pattern to use... though maybe that's cause I just apply the term repository to anything that accesses data from the outside world.
This is a great video. I've been experimenting with clean architecture lately but have never gotten a straight forward example of what it looks like. My current style of implementing it is based off my interpretations of snippets from other posts. What you've described is pretty darn close to how I implement it which is very encouraging and shows me that I'm not just crazy.
The grouping of all the pieces in a single file is interesting to me. I can see how, for smaller projects it might be OK but even that small example you had made that file enormous which might be unwieldy. I definitely think for a larger project, it might be worth it to use a folder for each feature and put each class in it's own file so as to have smaller, more manageable files. Though I definitely see how that can lead to times where you're flipping back and fourth between lots of files when you're working with the whole stack
First Clean Architecture talk I've seen/read online that acknowledges the difference between Afferent and Efferent coupling, rather than just saying "NO CODE DEPENDENCIES!"
In the clean and onion architecture (aka hexagonal, akaports and adapters architecture) the idea is that Infrastructure is decoupled from Application and the consumer (Web) is responsible to plug in the concrete implementations of Infrastructure at runtime. The interfaces(contract) of the Infrastructure is usually stored inside the Core project.
That leaves us the freedom to switch any time the Infrastructure implementation to another concrete implementation depending on the situation/providers and so on.
Thanks for the comment. While that's true conceptually about using different implementations and just depending on an interface, I don't think many people actually do that in practice beyond testing scenarios. And if you do, I'd argue that swapping implementations isn't straight forward if you have unknowingly leaky abstraction. I'd argue it's more about coupling as I mentioned in the video. As I mentioned, I'm more concerned about keeping small units (groups) of functionality (vertical slice) that define their dependencies and decide if they need abstractions on them. If you do, great, full steam ahead with Clean/Onion/Direction of Dependencies. If your slices are small, "freedom to switch any time" is a matter of changing the dependency, which isn't a nightmare if you're units are small. Again, I appreciate you taking the time to comment! Thanks!
I see your point and I admit it is fair enough.
I also see that some type of Infrastructure components it is better to be plugged in at the consumer startup or even switched dynamically on runtime based on some other criteria.
Example of components we want to be generic and be switched:
- email sender provider
- data storage (even databases, caches, entity framework)
- other external service providers we want to "adapt" for our system.
Wow, finally someone giving a proper analysis to the Clean Architecture. Agree 100% on that Dbset dependency issue and also there's another one that I still didn't find resolved anywhere and that is the isolation of Identity. Having my own User class, how to isolate the domain objects used by Identity without referencing the library? Great video. Would love to see your approach and a concrete example of your solution to my questions.
The core would have a User concept, and then the domain/UI layer would wrap that class. Not sure why this is a problem? Maybe I’m not fully understanding your question.
Let me think it aloud here,
Is a user class central to your domain or is it a concern of AuthZ and AuthN.
If the User class is your central concern, both the identity server and inbuild identity prodivder let you to configure things in appropriate places i.e. User object can be extended in domain layer and configured in infrastructure layer and the packages do provide such granularity.
If the User is not your central concern and it is only for AuthZ and AuthN (and related uer profile data) the defaults would do right?
Your videos are awesome!!! Thank you for the amazing real world approach to all things C#!! You take a real world approach which is very helpful compared to 99% of others which take a “proof of concept” approach.
Please keep it up! Been watching your videos all night
Glad you like them!
I feel both strategies work well together. Package by feature and then package using Clean Architecture within those features. However, my C# is very rusty so not sure it's applicable. But great video none the less.
I wouldn't couple UI to the domain though. When the client decides that the UI needs to aggregate results from a middleware abstraction, you end up doing more work. But each project is different and doesn't necessarily fall into the same scope.
Really helped out a ton! Currently using this architecture as well, but been eyeing on the loosely coupled monolith example you made before as it seems a lot easier to take out parts and put it into microservices if it becomes a requirement. As well as the code that should be together, should live together argument.
I simply prefer to think vertically (loosely coupled monolith) rather than horizontally. With narrow vertical slices, abstractions and layers matter less in my opinion. They are still important and so are abstractions, but the concern is less because being coupled to anything you down own has less of an impact if it needs to be removed. Also focus on capabilities rather than technical concerns is a giant win to get out of a CRUD approach where it matters.
@@CodeOpinion thanks! would you recommend a loosely coupled monolith for a LoB app for insurance brokers? It's a very data centric business, but part of it does a lot of things with the data. Would really get into DDD with it but having a hard time splitting those entities out as it seems impossible in my scenario.
@@CodeOpinion I think there is some confusion on how Vertical Slices approach presented here compares with the Loosely Coupled Monolith in your other video. If they are in fact the same, it would be nice if you could clarify how you implement a local Message Broker inside this vertically sliced loosely coupled monolith.
Layers and interfaces definitely don’t scale well with complexity. Slices like you described do.
Having the flexibility to choose transaction script, domain model or event sourcing on a per slice basis as well as only ever adding code to implement a new slice works great with large apps.
Another great video!
Thanks!
Another great video. To be fair, I think Uncle Bob specifically mentioned that architecture is about risk management etc (the "tension diagram" towards the beginning of the book) but more importantly that his 4-layer diagram is an illustrative example; that there could be more or less layers. I think it's tragic that so many "clean architecture" examples shoehorn an application into the 4-layer paradigm.
Project triangle for the win. Figure out which corner matters least and choose the path accordingly. Taking the time to make a GOOD abstraction is always a step in the right direction for quality. Understanding project scope and not wasting time on abstractions that will never be relevant is always a step in the right direction for cost and time.
Afterthoughts:
Deployment matters. For you youngsters: there was a time when software had to work and be close to perfect by the time it went into production. Video games used to be distributed on cartridges and optical discs. Updates were not even a possibility, so abstractions would have been ridiculous outside the context of a reusable video game framework. There are still some systems that operate like that (non-IoT embedded devices etc).
Check out the "when to use" section of the GoF Design Patterns book for the "Bridge Pattern" ... if I recall correctly, it says you shouldn't use the Bridge Pattern when there's only going to be one implementation. The Bridge Pattern is basically two layers of Strategy Pattern organized by role and a perfect OG example of a clean 3-layer architecture; Inversion of Control employed to isolate application logic (i.e. the "Abstraction") from the drivers & frameworks layer (i.e. the "Implementation")
#UseTheRightTool4TheJob
Thanks for the comment and good insights
@@CodeOpinion just trying to add to the discussion 🙂
liked the idea that approach differs per feature. At the end its just about knowing solutions to problems.
I don't see that you should do a specific pattern, but live up to the principles as long as they serve your needs - being pragmatic. The rest is just project style. In the beginning I took a "template" and modified that to suite my needs. Now I understand the principles, where that template fails for me, and can do all from scratch - without the template
Would love a follow up video on using IRepository in the application layer and implementing it in the Infrastructure layer with DbContext and Entity Framework as the Data Source
Now this is just quality content!
KILLER Analysis!! Well done! I think they have used your feedback to create an improved version
To me clean architecture is the same as onion. I dont get the rename.
Agree. Various forms with slight differences in definition but ultimately it's about coupling and direction of dependencies (afferent and efferent coupling)
Agree as princepls, but even you when you are implementing the architecture, you will find your self creating slitlly different version from it
"Clean architecture" sounds more silver bullet solution.
Uncle Bob: O, you have a mess of an architecture, just use Clean architecture
Dev : ok, thanks, but I don't know how to implemented
Uncle Bob: I do, but that will be XXXX dollars / hr
Uncle Bob and Simon Brown describe the difference in the last chapter of the Clean Architecture book. Small details, but important ones.
11:02 Seems to sound like an archetecture mentioned by Jimmy Bogard. Vertical Slice Architecture which is basically a Single Slice of Clean Archetecture where all(mostly) code resides
I had the exact same reactions to just about everything you've covered here. I love the architecture, but this template is not great. I think I just lean into abstractions from the very beginning regardless of the size of the project (unless it's super tiny of course) because I have personally found more benefit over time than cost. The greatest cost I've run into over the years is uninitiated developers. I think the way you described the grouping of functionality falls under another uncle bob concept which is 'screaming architecture' and I fully agree with it.
Yeah, exactly. I really appreciate his "screaming architecture" principle. The only thing the "interfaces-controllers-application-domain" grouping tells me is that I'm looking at a clean architecture. I really enjoyed "the Missing Chapter" of that book and it mentioned the pros and cons of a few different ways of organizing code.
MediatR != Clean Architecture
Use namespaces for vertical slices (contexts and features).
Use projects for horizontal layers.
Keep Infrastructure issues separated and limit the visibility of third party dependencies by having more that one Infrastructure project (one for UI, another for persistence, another one for messaging, etc.).
If your IDE does not let you see all classes of a given feature (namespace) across all projects, it's the IDE's fault, not Clean Architecture's.
YW.
I am a Java developer. To do Clean Architecture, I would prefer creating a multiple module Maven or Gradle project. The interfaces and classes related to the different levels of abstraction, e.g. Domain, Application, Infrastructure, Web are placed in their respective modules and the dependency among the modules are configured with direction pointing toward the center of the Clean Architecture circle. By doing this, you won't mistakenly create a reference to classes or interfaces residing in the outer layers.
You're the kind of guy that will be preaching beem/elixir/erlang in your future.
Ha! Curious, what makes you say that? I don't think you're wrong.
Putting the controllers in the application layer was very interesting to me for authorization reasons
In my context, I don't view authorization as a web concern because HTTP is just one of the methods to interact with the application. I need a common authorization if its an coming form ASPNET Core or say a Message Consumer. So it depends on your context.
Thanks for the explanation. Good food for thought. A tomatoe vs a tomato or maybe not. Good stuff
One thing that makes my head spin about Clean Architecture is that the diagram states that in the green layer you implement your gateway (repository) but a repository is related to a database, which in this diagram... is in the outer blue layer. So if I were to strictly follow it, it's telling me that I would need to create an abstraction between my repository and the database driver/ORM. Same goes for the controller, e.g. according to the diagram my mvc framework needs to live in the blue, but I should also have a controller in the green. What are your thoughts on this?
It should. You don't know if you will always use a database. The layer that cares about the data does not care about 'how you get it.'
I tend to always wrap an ORM. Small projects it doesn't matter as much but define small. The reason I wrap those is to remove the dependency from the business layer. The business layer has less reasons to change and you control the interface vs ef core. The business is the most important part and tends to out live all other parts of the application. In a perfect world this is how it would be done within clean architecture, however I have seen more of the opposite. My main argument is that the critical piece has less reason to change and therefore more loosely coupled to the persistence layer. I can think of several reasons as to why it would change and have seen those.
You can also use some abstraction like the specification pattern to abstract out filtering and pass that downstream to the repository layer.
hey, I'm a big fan of you and I like the vertical slices arch you introduced in the video, I have a question, do we still need Mediatr since we can directly write the application logic in the controller action, and we can also use the controller filter just like Mediatr pipelines?
That’s why reference /sample application implementations can be more useful than templates. Templates tell you this is the way you do things no matter what you’re building whereas samples tell you this is one way you can build that type of app. Templates also give you a starting point that makes assumptions that may not be valid for your use case.
That's a good way of explaining the difference. However, I often even have trouble with sample applications because they still don't often explain the reasoning behind the decisions. This actually makes me think sample apps need to include Architecture Decision Record (ADR) in markdown in the repo.
@@CodeOpinion oh definitely, 100%. A sample app without design docs is useless.
Very interesting work. (as a nit - the aspbergers kid in me can't get past your flipped video. "Reebok" belongs on the right) I'm subscribing!
Ha! I've had that comment before. It's so I'm looking in the same direction as the screen when recording. Otherwise I'd be looking in the wrong direction which seems odd.
I was asked this question during job interview came here to know the answer. I'm not really good at definition of terms interview I think I screwed my interview. 😭😅
Thanks you so much for the explanation.
Not sure I agree with the controller being in with the handlers as it's still a 1-1 for the command and controller. So you could just leave that in the UI project and not need to reference NetCore lower down. For me I try to make Infrastructure and Core levels in NetStandard so that I'm not restricted on the entry point projects type Xamirin, NetCore, ML. Love the videos though, keep them coming
Absolutely, if you want to re-use the application layer in another top level (xamarin) where you absolutely do not want to reference aspnetcore. But again, if you aren't doing that or the reference doesn't matter then it's something to consider.
This is just the solid dependency inversion principle but made into circles for some reason.
Physical boundaries nudge developers in the right direction. They create a path of success. If however, a dev really goes out of his way to get his feature working by crossing these physical boundaries then it would be pretty evident for a code reviewer. The bigger the team and the rate of incoming commits the more important this becomes.
I’ve used the principles described here but never realised the template was so… UNclean !
I wouldn't say that, think it's just a decision they made since they didn't want to introduce a repository, since a EF Cores DbSet is one. But then you leak that dependency and it has implications of knowing when it actually materializes and makes database calls.
I quite like the idea of putting command handlers in the same file/space as the controller that calls it. Our complex domain aggregates tend to have many different ways they can be mutated, so the file would be thousands of lines long. Also our domain gets called by a lightweight CLI/Service that shouldn't have any knowledge of ASP.NET core. So that's one reason not to. For this app, I do like your arrangement.
We still group things together by aggregate. As we evolve our structure (we're porting currently from old skool 3-layer MVC->BLL->Database to Brighter/Darker Command/Query) then there's plenty of opportunity to structure along the way.
Food for thought, thank you.
One feature I'd love in C# is a namespace-level accessor. Like private/public/internal, called 'spaced' where that type is only accessible to its namespace and the namespace children. It would allow me to form boundaries between aggregates that can be caught at design time.
When I do my Unity game dev hobby stuff, I structure my projects very differently to the accepted wisdom. I group by feature - just like you recommend.
I also have services that invoke commands via message dispatcher that leverages the same code. The reason that ASPNETCore dependency is not a concern is because some of these message consumers generate emails which we leverage ASPNETCore & Razor.
@@CodeOpinion ah ha! I did wonder. That makes sense. We use Razer the same way! For the moment we've also got that reference in our domain for the same reason but I'd prefer it to be an event handler, dispatched after the command so that failed sends can be dealt with polly. That's for the future! Thanks for the insight!
I see this template as a good learning tool, in that it highlights some of the code structure issues faced by non-trivial projects that people will encounter. One of the key points to bear in mind is it is supposed to give a structure within a team environment, where multiple developers are adding features over time, and a well known standard has to be applied for various features and bug fixes, maintenance work etc. as team members come and go. I can see value there, in formalizing an approach that has wide industry awareness. It could also be appropriate when attempting to modernise a brownfield project, giving a target structure for gradual migration.
But, I personally don't see it as my default *starting point* for an application; I don't begin with layers or abstractions, I refactor to abstractions or patterns as and when they are useful.
So from my personal preference, I do create templates for Unit and Integration Tests. Then I follow a lightweight TDD / BDD approach for use cases, which drives my domain model and the relationship between components. When that has reached a stage where the overall domain is apparent (even if not complete and will of course still evolve), I can then look at structure, and how best to deploy it. That might be an approach similar to Clean Architecture deployed to a web server, or it might be a fine-grained Functions based approached, containers etc. there are of course multiple factors to bear in mind.
That then guides me in how far to go in creating the abstractions / layers etc. - we've already covered testability by following TDD, and when the deployment model is determined, we can start creating integration tests.
Typically I use Visual Studio Snippets / Rider Live Templates, rather than full solution templates. It gives a nice combination of common approaches to implementing patterns, without specifying that they must be implemented whether or not they add value in the specific context of the application.
Oh, and repositories are a useful tool - not everything within a repository has to be a database accessed via EF. Dapper, storage, queues, etc. I always find it amusing that the people who are so definite regarding repositories as redundant due to EF, are often some of the biggest detractors of EF, and would dump it in a heartbeat if an when something better comes along.
I also use Rider Live templates for single files. I'm not for or against repositories as a global statement. It really depends for me. I often see them used where I would not though.
Aaaaaaaa
I think what you're looking for is to have a package by bounded context (or feature - although feature is even smaller), then inside of it to have have DDD for that bounded context and hexagonal architecture. This way you have high cohesion.
What do you think?
When you say "package" I'm assuming you mean some unit that you can reference from other "packages". In the sense of a package manager and dependencies. While you can use this approach for separation, you don't have to. Ultimately it goes down to "logical" decoupling. How you want to handle the physical aspect is a separate concern.
@@CodeOpinion yes, it's a logical separation. But as you said, if you want to grab a functional piece of your system and put it elesewhere, having each piece under its folder (with its domain and infra) allows that.
Another thing, I know the separation is logical, but the high cohision part is related to folder, isn't it?
I've been reading the book "Clean Architecture" by Uncle Bob and I think this "Clean Architecture" template project looks more like a typical DDD project. I am confused now. So what is the difference between DDD and "Clean Architecture"?
I've looked at various implementations and all are slightly different in naming and exactly which technical concern in is each. However the goal is direction of dependencies and coupling.
I'd argue that the focus of each term is different. In essence, they are not two conflicting ideas. You can absolutely have both.
"Clean Architecture" is more focused on decoupling different pieces so that they are swappable in the future.
DDD, on the other hand, is more about a mindset of understanding your domain, including the language/term people use and the domain constraint (business logic), e.g. a locked discussion thread should not accept new posts, etc. Such logic should be mapped out in the domain layer. Otherwise, the domain entities become what's called anemic models. Subsequently, service/application layers get thick, which leads to a very procedural style of implementation.
DDD is a design approch more like OOD
I hope if you can make another video about this nice way of application architecture, it looks very interesting
Yes, I'll elaborate more in future videos.
Should Clean Architecture be applied in small microservices or small micro frontends?
If you're trying to isolate domain logic, then sure. Check out this video where I talk about the purpose more: ua-cam.com/video/L2Wnq0ChAIA/v-deo.html
A simple rule of thumb for designing DDD approach is never think about database, table's, ui etc. Focus on domain object and it's behaviour.
Incorporating DDD in clean architecture is where we get lot of questions like which layer to place each stuff. After reading many articles on internet, it would put us on confusion.
Example: few justify repository interfaces should live in domain layer. Few say it should be in Application layer. Few say avoid factories for creating domain instances. But practically I see factories are very useful in creating domain instances. Few say don't use factories and use builder.
It would be great if software community creates a sample project to showcase how it should be done correctly with justifications.
I am glad I learnt certain standards and practices to follow from microsoft eshoponcontainers project. But not getting certain answers from the software community like: how to achieve event sourcing and publish integration event to event bus while using microsoft asp.net identity?
Is there any portal where all of the if's and why's are answered with justifications?
If I understand correct, App layer keeps abstractions, DbContext and does everything. Infrastructure layer does implementation of App layer, Any UI can have reference of infrastructure layer and consume App layer. Domain Layer keeps only entities....? If so, Seems App layer should be closest layer to UI.. (while UI using MediatR services there ). Would it be a choice to carry abstraction(interfaces) to domain layer , implementation and DBContext to infrastructure. App layer will have all others and reference of infrastructure. UI has reference of app layer. ???
Purpose of the domain project is to silo your core domain (object model) into a project with no references. The reason for the no references is to eliminate any efferent coupling in the domain project. You can ultimately structure however you want, but the purpose of this is really to reduce coupling.
the point is to get folks start with something mean to become bigger thing. when you bake the controller into the application you cannot reuse this project for a console application. the point to separating projects is that you can put any new UI technologies on top of the application project.
Sure, if you are going to be a new UI tech on top. If you do, by all means separate out the controllers if that's what you want. Having said that, the controllers won't stop you from adding WinForms. It's just dead code.
what's the diff between enterprise biz rules and app biz rules?
Great video and analysis of this template. Although I will note that the criticisms you raised are actually addressed in Jason’s talks and documentation. They’re not arbitrary choices or glossed over, they’re deliberate choices that he explains.
Also early on you make a comment about this being a template and then go on to say it shows a simple example and it’s not suitable for something this simplistic - Jason also emphasises this himself.
Thanks for the comment. It wasn't intended to be criticism of the template, him, or clean architecture. My intention was to explain the value in which context to apply clean architecture. Unfortunately I watched his talk after I record this video (someone posted it to me where at the end he talks about it)
Clean architecture Vs n layered architecture... Pros and cons... Please shed some light
I'll add it to my list of topics. Thanks!
Thanks for this great video, very useful and abstract :)
It is encouraged to make a video about the abstraction of ef core context or the design that should abstract the access to the database in this architecture, with some other than ef.
Keep going!
Thanks, again! +1
Thanks! Appreciate the comment
It's funny to see that "clean" architecture leaks the abstraction of specific framewrok (EF) into the contracts therefore forcing one side tto expect the other to be using the EF. To me this is really a smell that the author of this repo doesn't really understand what intertfaces are for. I would like to see him swapping the EF with MongoDb Driver without breaking this DbSet-based contract
I don't disagree, however it is an example. The reason being, my guess, is because he did not want to add a repository. Because of this, the DbSet must be there in order for change tracking to work with EF.
@@CodeOpinion Well, CRUD based repo is a strange idea itself to me and it would be better to have FirstClass abstractions that execute specific business rules rather than exposing the direct reference to db collections 😅 Of course, one can argue that this is just an example, but this is specific place with interface containing DbSet is literally an example of how not to do it 😅
i guess with more yr of experience, you would less obsessed with perfect clean code , just kidding ha
@@CodeOpinion exactly, also, come on, do we really expecting a sample template to use for real solutioning? thats wrong expectation 😂
Adding an abstraction is not just about swapping the ORM. The main value of abstraction is that you will have a single place for all calls to db and it gives great flexibility. Just imagine that at some moment you will need to mark entities as deleted instead of physically deleting them. If you have abstraction you will do it easily in a single place
Hi , thanks for taking out time to explain in detail. I've always wondered if CA was any use in small projects. Do you by chance have a repo to the approach mentioned in the video, something in the line of a sample project that demostrates the use?
All of the code samples I made are available to Patreon on UA-cam Developer members. Check out the links in the description of the video for info. As well as the link for the original template which is on GitHub.
Thanks for this great video. Would it be possible to have a look at your version of code in some git repo please?
Hi,
Thanks for your helpful video.
What do you do for abstracting EF Core context without leaking abstraction? Here we used DbSet in the Application layer, and it is leak of infrastructure in the application layer.
What is the solution to this problem?
Don't abstract EF. Otherwise if you insist on creating an abstraction, then use a repository.
I have done an abstraction of EF without leaks. So now I have my own adapter for dbcontext. Dbcontext it is already repository so I am avoiding creating some new repository. I just created my own dbcontext which is just adapter for EF dbcontext
Thanks for your suggestion, could you share your code?
Just joined your channel, it's amazing! I have a question though, how do you restrict the access on the repository only for the joiners?
Check the community tab where I post that only members can see.
Vertical Slices - That is Boundary Control Entity or what I call it, bug-fix oriented design
Boundary Control Entity? Not sure what that means. For me they are functional cohesive group of related feature(s)/behaviors.
@@CodeOpinion It's a way to structure code. It was introduced in the book Object-Oriented Software Engineering: A Use Case Driven Approach by Ivar Jacobson
@@CodeOpinion en.wikipedia.org/wiki/Entity-control-boundary
What you're saying makes a lot of sense. But isn't the reason for the IApplicationDbContext interface so that the Application layer can use the DbContext features without explicitly depending on the Infrastructure (outside) layer? i.e. Inverting the dependencies. I agree it sort of falls apart when the Application project references Microsoft.EntityFrameworkCore, among other things. I've seen some Hexagonal Architecture examples in Java but am new to Clean Architecture in .Net. It all sounds good on paper, but virtually every .Net repo I've seen so far has violated the principles in some way, at least as I understand the purpose of each layer, which I may be mistaken.
Yup. It's just that interface exposes the dbset which defeats the purpose IMO. Because of that you have to have knowledge of when a interaction with it actually makes (materializes) a call to the DB. It's leaking that.
Would you make a video showing how to really do it just to get the base idea of it.
How to "really" do it depends on your context. The template is a good example in itself and it will likely fit many use-cases. I prefer a bit of a different approach because I prefer smaller units of functionality which lets me determine each units dependencies. By doing so, I can choose to use the dependency without worrying too much about creating abstractions.
Can you please make a video explaining the Modular Monolith project template in detail?
Github -> kgrzybek's 'modular-monolith-with-ddd' repository.
Thank you!
Thanks for the suggestion, I'll take a look.
Nice stuff!
Overall video was helpful. Appreciate!
But your verticle slice implementation is breaking a fundamental rule of Clean architecture. In CA, the dependency should point inwards and not outwards! When you put controllers in Application layer, now presentation layer need to reference Application layer (ideally it should be other way around) to register those controllers to web host!
And also all related things for each domain are in one folder, so I think it's already better to discover those things. Controllers are outside in other project, because that is presentation layer and there might be multiple presentation layer in real world using same application layer!
Yes, if you prescribe to clean architecture. I generally don't as I'm more concerned about small units with high functional cohesion. Because their low footprint, I'm not as concerned with layers or abstractions.
Hey bro great content!
I would love to see your point on the repository pattern alongside with the unit of work pattern using ef core!
I'll do it eventually. It seems to be a absurdly divided topic which is hilarious to me. There are people that are in favor of it and people that aren't and nobody in the middle.
In the project I’m currently working we are doing ddd and I can “accept” the need of the repository pattern in some entities but I can’t see the need of unit of work as my dbcontext does that for me… but I’m just a junior dev trying to understand big guys worries here!
I will be checking in for that video! Thank you!
@Satsu that’s a solid reason for me 😬
Great content. Your solution might also work well with Minimal APIs
Interesting approach with controller in same file. What if the controller has more actionmethods? Which is quite common. Do you make it partial and split it up?
I generally only ever have 1 or 2 actions
@@CodeOpinion Don't you have GET, POST, PUT/PATCH ? Maybe one GET single item and one for a collection?
I suggest you read the book Clean Architecture and then tell us your opinion. One probably shouldn't judge something when they haven't even read about it from the original source. This template doesn't demonstrate the Clean Architecture.
Curious, what about this video did you disagree with? That I didn't correctly explain what clean architecture is? Or that I used a template that didn't follow it. I did explain that the template didn't follow it. I also hope I was explaining the value in Clean Architecture is about direction of dependencies and ultimate as usual about coupling.
Great Review!
Thanks!
Awesome content
You cannot call this template Clean Architecture if it violates most of the dependency rules. These interfaces also seem to live in wrong place, these gateways and interfaces should be part of the domain/core. Todo is worst example to display on Clean Architecture anyway, no business rules at all in core as you mentioned.
Like I said, templates and examples are difficult because they need to be simple enough to explain, yet not complex enough that all is lost. However, simple examples tend to lead people down the wrong road if they don't understand the full context. It's difficult and I struggle with it in my own code examples.
Why gateways / repositories should be part of the domain layer? Genuinely curious, as they're objects that should not be used in domain layer but in application layer - we can call them adapters if you want hexagonal-ish terms. Besides, typically you try to reach domain purity working with in-memory objects, not out of process dependencies.
@@iorch82 I meant only the interfaces. Your core should never know where the data comes or where ot goes to. In Clean Architecture diagram they are same as input and output port interfaces. You put them together with your core domain, because they are USED by core and IMPLEMENTED by adapters. This allows you to test your aggregate/core/domain using nice simple mocks by implementing these small interfaces (usually one method inside them or functional interfaces) in-memory.
Jason describes the EF dependency and the rest of the template here: ua-cam.com/video/dK4Yb6-LxAk/v-deo.html
As I mentioned in the video, I'm fine with ditching abstractions and going "all-in" if you think it's worth it for your situation. However, if you are, then don't bother trying to create your own abstraction on top and lose all the functionality of it.
@@CodeOpinion There is also an advantage in selectively choosing what to abstract. If there is no expected future pain, or abstraction doesn't solve it all anyway (eg. relations with EF vs. event store), and the abstraction cost is high, then I wire it in.
If, however, the abstraction cost is low, the current implementation is a commodity (eg. a CSV library), future pain expectable, then I abstract it away in a separate project.
Cool Video
to me clean documentation is better than clean architecture.
also when it comes to abstraction 2 -3 levels is enough and it must go down the folder not bouce around
Idk, have seen this template over the years, seems overly bloated for small/medium projects. Repository pattern is stupid for EF Core. Having 100 layers to use Newtonsoft.json is also dumb, you are never going to change it. It's not a library from a random guy that may get removed/dropped. Also the template uses a mix of razor + any frontend library , uses razor for auth. Don´t understand WHY would you mix your API with a Partial HTML response ever.
Like the idea of this, but overuse of abstractions and interfaces is just annoying. If your db has 10 models and 5 controllers, it does not make sense to have 25 Dtos, 10 repositories, and 50 abstractions with 5 layers of services calling each other. You end up using more time to code all this and do not even start about the tests for each thing here.
Oh great. Another fancy term for relies on, or doesn't.
Coupling? Not really a fancy or new term. Probably the thing least understood that is the cause of most of the complexity written in software in my opinion.
I think this is a bad example. Truly people should know and understand software boundaries. This is not good seperation.
I don't like having multiple types in a single file.
For more complex Projects why just not split verticaly, but add projects as layers too? Yes a lot of solution folders and projects, but much harder to make mistakes.
I would like to work for models, handlers, validations, events from the same file… but you need much more discipline and for every team member to actually understand the problem.
I find most developers work based on the existing structure. They mimic/replicate what's already there. If you are organizing a certain way, most folks will follow the same standard.
@@CodeOpinion yes for common problems... but then something more complex will come up, and one developer will make a shorcut, and then the other one... and you will have chaos...
No. Just no. Where is it clean exactly? There's so much noise and unnecessary interfaces and classes. It's crazy! An architecture is clean when you know where to find stuff. Here, you're completely lost. It too much!
Efferon coupling and Afferon coupling. you need to find better words, these make no sense t me and i can’t even hear the difference.
Not sure how I find alternatives, that's what they are. Afferent and Efferent.
Yup, useless abstractions and artificial divisions provide an illusion of clean code, while actually incurring a maintenance cost.
Look at all these leaky abstractions. Here is my much better solution with leaky abstractions but thats okay because they are mine...
This sadly is a bad example of clean architecture which is why you don’t need to or should use it. I’m typing with one finger otherwise I’d happily go into why 😛
I meant the template, not the other parts of the video…
All good n' all but: Opinions will be opinions. I get that people find some approach more useful than others, I get some ppl get "married" to certain technology or platform, all that is OK. The onl... ERASE Entity Framework!! NOW! incarcerate the maniac that came up with it, melt the key and pour salty water in the door lock!
Besides it takes a lot of extra time with no added gain, and makes the boilerplate a horrible broken-rows mess. Who in his/her sane mind will prepare a whole application to be, not only DB agnostic (which I adhere, of course) but "automatically" deployable.... what comes next: auto-migration? What the million other approaches to persistence out there? are SQL based a must?
I get people have to find some work to do at Microsoft these days, but c'mon! do something useful, like that time when you did MS Messenger, or BizTalk in the early 2000s, or SOAP and webservices... at least seamed that you cared...
Be a professional: manage your entities! (Rant is over)
That's my CodeOpinion. The videos are awesome, by the way!
someone educate me: What the hell is Clean Architecture? Why that stupid name? and Why should I care?
watch the video:)
I disagree that the point of the domain layer is to have business rules. The domain layer is simply your core models, no logic. The application layer holds all the logic, in this pattern, the queries and commands. And I think that is a very clean separation
However, I agree on every other point
If you don't have any behavior or logic on your "models" then I'd call those data models, not domain models. If you're relegating your business logic in some type of application layer, then you're using what most would call a transaction script.
Sorry, what? Where did you learn DDD from, Twitter? The book defines domain layer as: [[Domain Layer]] That portion of the design and implementation responsible for domain logic within a LAYERED ARCHITECTURE. The domain layer is where the software expression of the domain model lives.
@@thatoneuser8600 how rude.
too much
Whats about embedded systems where should be device-specific implementations? for example steppermotorN34738.step(20)
Very practical
Great content. Your solution might also work well with Minimal APIs