This is pure gold. A really solid architecture. I'm going to be using this in all my future projects. Thank you!
@ratowar3 жыл бұрын
It is a solid architecture, but I wouldn't use it as a silver bullet
@sechabamotaung8552 Жыл бұрын
Havent been this attentive listening to a talk for a really long time. Love this project template, thank you.
@TheMiamiVice274 жыл бұрын
I am amazed how good is this Onion (Clean) architecture! I have experience working with CQRS in a similar way, where we have our custom http pipeline (In that time there was no MediatoR) and I was furious why are we doing it. But as my experience was growing I had an "Aha!" moment when the puzzles matched. Our enterprise is still using some "old" tech but privately I am sold to this architecture. The ability to automatically read all your endpoints (with DTO-s and ViewModels) and build TypeScript Services for accessing backend was an eye-opener for me. Because in the past I was spending too much time writing TS services to match backend endpoints. Thank you Jason for explaining whole solution and pointing out the real stuff!!! Keep up the good work! Greetings from Croatia!
@CodeSbyAniz4 жыл бұрын
GREAT TUTORIAL AS ALWAYS! This channel is providing so much value. Keep up the good work!
@sen.alexandru4 жыл бұрын
Amazingly clear and useful content. Congrats!
@Endomorphism5 жыл бұрын
Whats difference bw ddd and clean architecture ? I find a lot in common..
@IshA-pr5zi9 ай бұрын
Thanks for much your best explanation on clean architecture
@aslanamca82253 жыл бұрын
I'm a beginner yet, but I want to ask a question. Diagrams describing clean architecture explain that every layer outside the domain should refer only to the application layer. The ASP.NET Core project in the presentation layer seems to reference the infrastructure layer to register the dbcontext class in the IoC Container. Isn't that wrong? If this is true then the asp.net core project needs to refer to each layer and register their services, isn't that a violation?
@stefangabor59853 жыл бұрын
Hi Jason, Thanks for the inside of this project. Looking through the project I find, however, that it is not quite low coupling since you have a dependency on EF Core in the App layer. I have been programming for a very long time and back in 80’s we had already built apps which had a better approach to infrastructure layer. We changed the RDBS vendor in a .ini file and the entire app was fully functional, regardless of the RDBS vendor. I cannot say the same thing about this project. Your thoughts?
@ali-13392 Жыл бұрын
I agree 100%.. Were you able to find an answer for it?
@stefangabor5985 Жыл бұрын
@@ali-13392 Absolutely, you must look to the past to find the answer. We built an intermediary layer on top of the repository, data manager layer, so that the UI requests get “transformed” based on the DB schematics requirements.
@younesk71114 жыл бұрын
Great presentation! I like the way you use the Chain of Responsibility pattern to conform to the Open-Closed Principle. But don't you think the use of MediatR seems invasive in the application layer? I also find the validation with annotations more readable, and I don't think they pollute our business objects since they're from a standard library.
@sergey5846 Жыл бұрын
Validation with annotations is not always flexible enough, especially when you need to make IO calls (DB, external API, etc.). Validation annotations will pollute business (domain) entities eventually. Every class, that tries to solve multiple concerns at once, will become a frankenstein monster as time passes. Developers will keep adding new fields/properties/methods and restructure it in ways that will allow you to properly validate the incoming data, to process your business logic, to send data downstream (IO, background processing, etc.) - all at the same time.
@shayankamalzadeh4 жыл бұрын
Why you use meditR in application layer? Application layer is depends on meditR,is it clean architecture uncle bob? I'm confused.
@ekhm4 жыл бұрын
Same for EF. Application depends on EF Core. That's not so clean.
@stefangabor59853 жыл бұрын
The entire Mediator idea either, I am not sold to it. It generates a lot of bogus code, completely screws up your POCO objects, your domain model, code reuse, etc.
@fnerf05 жыл бұрын
If you think that audio is ok, it is not. Just double it in the future.
@ladislavmacejak32303 жыл бұрын
Does not the fact that Application project references Microsoft.EntityFrameworkCore package make application layer dependant on infrastructure concerns?
@SuperDranger4 жыл бұрын
who gave this a thumbs down? its really good!!
@SuperCustomer0075 жыл бұрын
Grate presentation, but for me it's still black area how to customize AplicationUser (f.e FirstName, LastName, Bio, Picture). How and where to deal with this (will it be IdentityDB or ApplicationDB). Looks like it should be part of Domain and Application but ApplicationUser in infrastucture...
@trongphan61975 жыл бұрын
Domain contains enterprise logic vs application contain business logic at the very beginning of the video. Can someone understand what he really mean?
@filipenobrega29645 жыл бұрын
From my understanding, for example: you can have a domain layer that is shared throughout several applications. So the enterprise logic stays the same in your company but the several applications may change
@youtube.com-handle4 жыл бұрын
from my understanding this whole thing is to map and convert the POCO (Domain) to DTO (Application) using the Mapper and MediatR while keeping the domain layer intact. future work might require different set of rules, i.e. logging every operation, validating requests, maybe changing a critical rule for the employee perse wont necessarily change the whole domain layer, migrating to a different dotnet will cost less.
@odairto3 жыл бұрын
Why the Application Layer is accessing the DBContext? This doesn't responsibility of Infra layer?
@shahkaleem66014 жыл бұрын
Do you have git repository or something similar.
@sudidav5 жыл бұрын
What happened to the sound? Thanks anywhere!
@lario815 жыл бұрын
Great video - very nice mixture of theoretical architectural layering and concrete implementation in .NET core and the web/database stack related technologies. I think that the template solution would be very useful starting point for a big project.
@jameshoiby5 жыл бұрын
Yay!!!! The sound is fixed!! Thumbed up immediately! Thanks for the great talk Jason, I love your teachings.
@someotherclown4 жыл бұрын
Perhaps I missed him mention this, but DbSet is exposed in the Application project creating a dependency on EF Core. Is this desired?
@Algorerhythm4 жыл бұрын
Jason talks about how you could do this by implementing the Unit of Work and Repository design patterns to abstract away EF Core. Watch at kzbin.info/www/bejne/a4DXhqBnd7GgfZI
@stefangabor59853 жыл бұрын
Hi Jason, There are better ways to implement complex rule validations without any changes to code, such as decision matrix, tables and functions, etc. These DTs would be exposed to the administrator and, as business rules evolve, very few changes are needed in the code. Keep in mind, that every line of code change is always likely to introduce bugs and therefore should be avoided at all cost. Again, this has been around since the 80s and has become very popular in recent times. Your thoughts?
@ChadGeidel5 жыл бұрын
Great talk, but it was difficult to follow along as the ToDoItems Queries aren't in the Github repo, nor are they in the Nuget template.
@xxmuffins352xx5 жыл бұрын
It looks like they are now. github.com/JasonGT/CleanArchitecture/tree/master/src/Application/TodoLists/Queries
@svntsn7154 жыл бұрын
Very interesting, thanks a lot for the clear presentation. I want to rework a heavy ancient monolith app into a clean architecture. The ca project structure you present makes it easy to see where things have to fit in and how. Correct about EFCore, no need to DIY. I'm fan of data annotations but I'll try fluent validation to understand the benefits.
@Dpaz20092 жыл бұрын
Fluent validation is pretty cool, it solves the problem of open-closed principal in domain classes.
@CrazyPilot3334 жыл бұрын
Where can i see all the code?
@feelingeverfine5 жыл бұрын
Thanks for the reupload. I downloaded it and upped it a bit more which works.
@aminejadid27024 жыл бұрын
Why the application layer depends on MediatR ?
@talktomenowxbmc4 жыл бұрын
It's bit confusing how to fit in IoC Containers (Autofac or Unity) within this diagram? Should it be part of Infrastructure or Application?
@louenjli8973 жыл бұрын
Hi Taylor, First thank you for this great video. I'm beginning in this new approach, and I have a little question. I have two action one for creating an item in DB and the second is to sending email(notification) after this operation. So, what is the best way to do that ? It is a good idea to have the two actions in the post of my controller: . . Post: mediator.Send(...) mediator.Publish(..) In first time, the command Send create the itm in DB and after that I use Publish for notification(sending email). Do you think it's a good way or is there another solution ? Thank you in advance.
@PaulSebastianM3 жыл бұрын
11:47 I don't understand what he means... that the system clock is an infrastructure dependency... having an IDateTime just proxying DateTime.Now seems redundant.
@WahidRezgui3 жыл бұрын
Hi, thanks for all what you are doing , I have one question : I cant understand how and when the command validator is invoked and how to return an exception to UI if there is a saving error for example
@Layarion3 жыл бұрын
To me it seems like c# needs to focus heavily on baking in and streamlining, as much as possible, these interfaces and abstractions. I get that it's got alot like that already, but i feel like it really doesn't do enough to streamline things that keep the code managegable.
@stefangabor59853 жыл бұрын
C# has nothing to do with it. The way one decide to build your app it is entirely up to you. I agree with you, however, that some if these requests and handlers generates a lot of unnecessary and convoluted code. The entire Mediator idea, I am not sold to it. It generates a lot of bogus code, completely screws up your POCO objects, your domain model, code reuse, etc.
@aiboltoleu1555 жыл бұрын
This architecture has been a while in software engineering and it's called ONION architecture. I would not say that CQRS is simple to implement. I agree that the idea behind it is simple. However, it implies that you are going to have message queue and materialized views in case you have relational database what makes application really complex if you want to apply CQRS pattern everywhere. Apart from that there is latency between when command persist changes to store and when changed data available for queries. CQRS should be applied wisely and not for each operation in the system. What I also don't like is how automaper is used. You get direct dependency on Automapper in query and command classes. What if you want to replace automapper with something else in future.
@NightBladePL5 жыл бұрын
MediatR is supossed to work as in-memory mediator, not your microservice infrastructure bus. Yes, the coupling with automapper is very strong in order to provide default common behavior which is mapping entity to vm. This strong dependency is present almost anywhere but lets face it, why would you change it in a mature project anyway.
@xxmuffins352xx5 жыл бұрын
I'm not a huge fan of automapper either, to be honest though with the way this application is designed it would be easy to remove it and just write the projections yourself.
@ecrondilla4 жыл бұрын
what happened with the volume its very low compare with the ads...
@timhosking3 жыл бұрын
If I want to define my database objects independently, how would I do that? I understand it is part of the infrastructure folder of the project. But I want to create a git repository where I can put database table statements, SQL schemas, constraints, etc. I want my .Net code at the lowest level (infrastructure) to call stored procedures. Any advice?
@nestorguemez4846 Жыл бұрын
Excellent content!
@robgrainger53144 жыл бұрын
It might be the trivial nature of the example, but as presented it seems to me a textbook case of an Anemic Domain Model.
@ThereCameAnEcho5 жыл бұрын
Any plans to offer this in 1080p?
@abdelrhmanelsaid45895 жыл бұрын
Great i have watched the whole video to know where you injected ApplicationDbContext to Domain layer but i didn't get it
@deepakpandey94064 жыл бұрын
It's in infrastructure layer inside dependency Injection class
@faisalmorensya49363 жыл бұрын
you did code using the Surface?!
@randomic_bear4 жыл бұрын
Can I reupload this with amplified audio?
@TheZigsDk4 жыл бұрын
Would you believe that this is the reupload with amplified audio?
@Fasiibcs4 жыл бұрын
Hello. Hope you are good. You have a class AuditableEntity in core/common project, but you never use it in configuration files. I have implemented it as base class for all of my entity configuration, and then now i am calling the "ApplyConfigurationFromAssambly(typeof(contextClass).Assembly);" in OnModelBuilder method. When I am calling the migration command, it returns empty database, empty in Up method of migration file. If I give "ApplyConfiguration(new EntityClass()); then it works fine. Please let me know the solution.
@andriizahr4484 жыл бұрын
32:00 UoW+Repo explanation
@mohammadj225 жыл бұрын
what if the user is not logged in? then it will always throw an exception whether the API is public or need authentication
@niroshanmanoharan42953 жыл бұрын
UOW and Repository Patterns 00:31:00
@Rene-zq3np5 жыл бұрын
is this neccessary to know for entry level devs ? juniors ? thx
@ivandrofly5 жыл бұрын
the volume is very low
@Gonkers444 жыл бұрын
Audio is very low. So now the ad audio blows me out of my chair when they cut in. 😤
@DriveU8364 жыл бұрын
Can you provide or point to a GIT Repository
@CrowJam4 жыл бұрын
Dont have the time to watch this atm, but does this have any relation to Clean Swift (VIP pattern?)
@jonperada2 жыл бұрын
I know this is old, but this confuses me with the key point "No layers depend on Infrastructure layer...". It contradicts what is implemented in the demo solution. The Web UI project depends to Infrastructure project.
@zihadulislam95 жыл бұрын
tell me, what're the prerequisites for watching the video? I am new in ASP.NET Core.
@filipenobrega29645 жыл бұрын
ASP.NET Core installed and an IDE (VS Code, VisualStudio 2019, etc.)
@taniax89444 жыл бұрын
Same as you I did'nt know anything about core, Just download the project (it's on github), Run it, try to understand, if you thinks you do, try to add some feature, fix your bug when you thinks you can go Let's started to build your own
@Layarion3 жыл бұрын
NDC, you have *a lot* to learn about audio loudness. This is ludriciously quiet that no normal set of speakers could even hope to play loud enough to be heard by anyone who's not in a vacant library.
@adriangutowski_4 жыл бұрын
I will definitely use it. Keep up the good work.
@RajaSingh0124 жыл бұрын
Any sample project other than northwind traders
@allmhuran4 жыл бұрын
Something bothers me deeply about clean architecture, even though on the surface I like it, and it is this. How often do you change your database technology, for example, moving from sql, to postgres, to cosmos, to postgres? I'm going to guess that the answer is "not often". How often do you change your domain? For example, adding a new poperty or method? I'm goingto guess that the answer is "all the damn time". So... the things that change the most have everything depending on them, and the things that rarely change have the fewest things depending on them. And this is... good?
@NiamorH4 жыл бұрын
This kind of architecture (onion, hexa) is designed to make it easy to modify the domain though, since it is not entangled with any infrastructure stuff, if done properly. The fact that you can easily swap the db provider is more of a consequence (but to be honest, EFcore already makes it easy for you, no matter which architecture you are using).
@stefangabor59853 жыл бұрын
More often than you might thing. Let’s say for example that you build an ERP which is very successful and that you use a data dictionary. Since this projet has grown out of the original intent you want to take out the entire data dictionary and place it into a different database, for optimization purposes. Building good apps is costly and this is where a good architecture makes all the difference.
@allmhuran3 жыл бұрын
@@stefangabor5985 I don't think that's a real comparison. Sure, I can imagine that you start some application using a dinky back end database like MS access or my sql, and you might switch to a real database like sql server or oracle or something ONCE. But you're not likely to be changing your database technology multiple times per year over the life of the application. The domain logic, on the other hand, changes with every feature you add. You're probably changing the domain weekly, vs changing the database vendor... what.... once every few years, and even then only in very specific scenarios. Most applications I've ever seen have never switched database vendors, even applications that are a decade, or even *decades*, old.
@stefangabor59853 жыл бұрын
@@allmhuran There is also another option, supporting multiple DB at the same time. The ERP is supporting MSSQL, MySQL, Oracle, and PostgreSQL concurrently, trough the implementation of a Data Manager. It is the APP which I was referring to earlier.
@allmhuran3 жыл бұрын
@@stefangabor5985 How does that make a difference? The point is about code which changes vs code which is stable. You could be supporting a dozen back end technologies, but that doesn't mean that you are constantly rewriting the code. Like "oh, I have to change it all for my SQL clients today, but tomorrow I'm going to undo all that and rewriting it all for my oracle clients"? No.
@denchernov94944 жыл бұрын
Thanks for the amazing video!
@zaingadol23615 жыл бұрын
I need to use volume booster to hear it but the echo is really annoying. Look like in down under (Australia) , everything are reversed.
@nclong925 жыл бұрын
Great job. Thank for your teaching.
@alireza1362115 жыл бұрын
Great presentation, lots of cool techniques.
@huray98024 жыл бұрын
Is there any way to get this presentation slides? Are anywhere uploaded?
Throwing exception for validation problems, doesn't that go against the definition of exceptions?
@bstaffe4 жыл бұрын
If you expect the input to be of a certain kind, but it is not, it's an exceptional behavior and should throw an exception. Especially if it gets past the usual validation coming from the front-end.
@vlasceanuv5 жыл бұрын
There is a link with the git repo of the project?
@erhanalankus5 жыл бұрын
github.com/JasonGT/CleanArchitecture
@samithraniroshana40895 жыл бұрын
Audio is very bad. Can you reupload this video with better audio
@brainoverflow983 жыл бұрын
Good presentation I've seen this a couple of years ago and it gave me a different point of view on architecture. But since then my views are changed. According to me most of the time the data model depends on the business logic and the business logic depends on the application type. For example if you choose to build a REST API application you are going to construct your business logic around it and your data model will be designed to fit this business logic. So indirectly your data depends on the application type. Because of that chances are you will never use the same business logic with a different type of application. To me it is pointless to try to separate things that can never be separated completely. For this kind of small projects concepts are simple so architecture is relatively “clean” but as projects start to get bigger you start to see concepts that do not fit into any specific layer. Trying to fit them into one layer only leaves you with confusion and wasted hours. Layers should appear naturally as you progress in your project while trying to make your code readable with correct abstractions. Modularity and abstractions will be different for every project based on the team structure and the project requirements, you can’t design one size fits all architecture.
@felipevaldes28735 жыл бұрын
Thank you for this. Can this architecture be applied to Non-relational Databases as well?
@Algorerhythm4 жыл бұрын
Jason talks about how you could do this by implementing the Unit of Work and Repository design patterns to abstract away EF Core. Watch at kzbin.info/www/bejne/a4DXhqBnd7GgfZI
@gabrielilie44605 жыл бұрын
Hi, What is the purpose of the IDateTime interface, can't we just use System.DateTime.Now. Since the DateTime type is part of the System namespace I don't see any value on creating our own abstraction. Thanks.
@zVolodymyr5 жыл бұрын
1. If you have time related behaviour, you may want to do unit tests for that 2. You customer's may be from other timezones 3. You may want to modify time based on some http header 4. Etc
@supern4ut33 жыл бұрын
It is to be able to mock the date and validate it in unit tests.
@nagasudhirpulla5 жыл бұрын
I was waiting for the audible video since the day it was uploaded
@StephenOwen5 жыл бұрын
The audio is better, next time turn those knobs up to 11 because this is still 10% of the volume of the video I just came from.
@hanspetervollhorst14 жыл бұрын
Slides would be great to follow along. I am having a hard time following his pace.
@jesperkped5 жыл бұрын
Sound is sooooooo low
@jonathancharlesbass5 жыл бұрын
Excellent talk 😎😎😎
@airat.sh215 жыл бұрын
If the infrastructure layer will depend on the domain as well, is it weird?
@xucongzhan91515 жыл бұрын
But that's the main point of clean architecture, isn't it? Making it easy to change to another stack for anything on the outer layer.
@Layarion3 жыл бұрын
"buisness logic is specific to this application" does he mean it's specific to the software running it, or the "real world application" as in, the approach?
@jgamer13944 жыл бұрын
Source code pls?
@superpcstation5 жыл бұрын
Thank you for listening, NDC :)
@NDC5 жыл бұрын
We try :)
@PyaePhyoAung-xi9fh4 жыл бұрын
Thank You
@ericserafim79544 жыл бұрын
Great talk Jason, thanks! God Bless you 37:23
@ivandrofly5 жыл бұрын
was looking for something like this
@elertan5 жыл бұрын
Ah I'm sad, I had already seen this talk! It was awesome and I was hoping for more content haha. Oh well.
@gonzalofonsecac5 жыл бұрын
Audio is too slow 😕
@mi595611 ай бұрын
I his calmness while talking.
@ilovepandaypoe60564 жыл бұрын
still very poor audio me. already 100% but the sound is just 50%
@PiotrGankiewicz5 жыл бұрын
An anemic domain, full of { get; set; } entities being processed by "services" is not really a clean approach.
@sjrsjr1235 жыл бұрын
Is Jason advocating an anaemic model?
@PiotrGankiewicz5 жыл бұрын
I don't think so, yet it would be nice to see (even a very simple) example of a proper aggregate inside a domain, as that's quite often the confusing part for developers (given the "Clean" title) :).
@pyrobolser5 жыл бұрын
Do you have resources on how to apply this or modify his current repo github.com/JasonGT/CleanArchitecture to avoid anemic models?
@PiotrGankiewicz5 жыл бұрын
Simply put - refactor TodoItem and TodoList into rich domain models, with proper encapsulation etc. where TodoList as an aggregate would be responsible (e.g. via custom methods) to handle TodoItems.
@sjrsjr1235 жыл бұрын
@@pyrobolser infoq have a great DDD as quickly as possible guide of you're new to the concept of rich domain models and DDD in general.
@sudhakarreddych5 жыл бұрын
Audio is very poor
@viruslab15 жыл бұрын
sound is realy bad
@SenthilKumaran4u5 жыл бұрын
Audio is extremely low, please re-upload with proper audio.
@chadiusmaximus93503 жыл бұрын
audio is so slow.
@codingstyle94804 жыл бұрын
Why is the lecturer whispering?
@linqlou6574 жыл бұрын
nice talk.
@umfaninoh4 жыл бұрын
Link to the repo github.com/JasonGT/CleanArchitecture
+NDC Conferences: What's wrong with your audio? This talk looks interesting, but I can't hear most of what he's saying which defeats the purpose.
@LilPozzer3 жыл бұрын
можно нщё тише говорить?
@einfacherkerl32794 жыл бұрын
Although it seems a fine design, there is too much unnecessary abstraction involved and it feels like over doing some of the stuff. For instance, I see no value in implementing IDateTime and using Now only be injecting a dependency which itself uses DateTime.Now in implementation. Remember that each function call has an overhead and using too many abstractions you are affecting the performance and also having unnecessary dependencies. Also in CQRS, the request should directly go to the command or query handler and there should be no intermediaries in between. To me it is sort of convoluted that before the request reaches the actual code (handler) it is intercepted by many pieces of code (IPipelineHandler) where they are not common but are based on what command or query is being handled. Object Mapping is fine as long as it is not overdone because the rule for mapping is A) either it should map to exactly one property in target object OR b) it must be ignored. So if you need just one property which is non-ignorable as is mostly the case, you end up modifying every mapping by hand which itself is a painful thing to do. .NET is a framework so whatever architecture you build should run side by side, not on top of it by abstracting the .NET framework itself.
@T___Brown4 жыл бұрын
Guess I am the only one who thinks this solution isn't a good idea. It isn't exactly fast since it uses EF, Automapper and Activator.CreateInstance. I have moved away from EF and am happier for it. Dapper is much simper and faster. CQRS concepts are good but not exactly doing commands with Web API's, maybe if doing GRPC. Web API core 2+ has built in code for doing validations and I agree with not using annotations.