Clean Architecture with ASP.NET Core 3.0 • Jason Taylor • GOTO 2019

  Рет қаралды 239,596

GOTO Conferences

GOTO Conferences

4 жыл бұрын

This presentation was recorded at GOTO Copenhagen 2019. #GOTOcon #GOTOcph
gotocph.com
Jason Taylor - Solution Architect at SSW
ABSTRACT
The explosive growth of web frameworks and the demands of users have changed the approach to building web applications. Many challenges exist, and getting started can be a daunting prospect. Let's change that now.
This talk provides practical guidance and recommendations. We will cover architecture, technologies, tools, and frameworks. We will examine strategies for organizing your projects, folders and files. We will design a system that is simple to build and maintain - all the way from development to production. You leave this talk inspired and prepared to take your enterprise application development [...]
Download slides and read the full abstract here:
gotocph.com/2019/sessions/984...
/ gotocph
/ goto-
/ gotoconferences
#SoftwareArchitecture #dotNET #Programming #CSharp #CSharpdotNET
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotocon.com
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
kzbin.info...

Пікірлер: 161
@F2H16
@F2H16 3 жыл бұрын
Domain layer - 8:34 key points 16:37 Application layer - 17:03 key points 31:39 Infrastructure layer - 32:07 key points 41:25
@Noceo
@Noceo 4 жыл бұрын
As much as I like software architecture, it often tends to get very fuzzy and abstract, when spoken about. Especially for newcomers (like myself). Therefore it's so nice to see a presentation with a lot of concrete examples and actual code. Great job!
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
Thanks, Noceo! 😊
@TrackerX2007
@TrackerX2007 Жыл бұрын
@@JasonTaylorDev Hi Jason. Great presentation! What or where is the best place to send email notification? For example, every todo list that I add will send an email to me. Is it on domain or application? Thanks
@Erril-1
@Erril-1 2 жыл бұрын
Thank you very much Jason. I really like Clean Architecture and your example solution is very straight forward and easy to understand. Only 1 thing I would not use: Automapper. I don't like Automapper because it hides references and increases in most cases the code reading time. I think most people believe that Automapper saves development time, but its actually the opposite. When I refactor code or implement new functionalities and I don't have the references which would tell me where all those properties are in use, I would have to constantly look through the AutoMapper mapping profiles from each type which is involved and try to figure out what is going where and what might break if I change a property, because the compiler wont tell me due to the fact that Automapper is doing everything during runtime with reflection, but during development time I don't get any help. That costs much more time than the time you maybe saving when writing the code. And I haven't even mentioned other problems which Automapper is causing like misleading of static analysis. If you want to shrink writing time, then look rather into the Visual Studio extension MappingGenerator on GitHub ;)
@sebastianbergman7810
@sebastianbergman7810 3 жыл бұрын
I did exactly this a couple of years back while modernizing an old webforms application, step by step! Awesome that there is new stuff on the topic coming out still. Tip for new comers is reading up on what Jimmy bogard has been blogging about for years, who Jason mentions as one of the disagreeing experts 😅 nice stuff!
@malehernandez1975
@malehernandez1975 3 жыл бұрын
I've been playing with this template for a while and now I'm getting the whole team up to a real product based on it. It has a very solid foundation, and it's a very approachable implementation.
@espvp
@espvp 3 жыл бұрын
Hi Alejandro, I'm genuinely curious about your feedback after using it in production for a couple of months. Thanks in advance.
@malehernandez1975
@malehernandez1975 3 жыл бұрын
@Andres Rondon, We are not in production yet because it's a large project. What I can tell you something about is adapting the system to our needs and the learning curve for me and my team. I have modified some things, the entire security (following a specific requirement), the entire UI as we don't plan to use Angular at all, and some other details. There was no big problems implementing all this stuff, as the responsibilities are very well segregated. I found useful to duplicate each layer, keeping the base proyects to reuse across all our future developments and putting our domain specific logic in separate projects. No problems with this either. MediatR is sweet, reliable, and enables a lot of order. The MediatR pipeline is very useful, but for the non-business related topics (as logging request duration, etc.) you have to evaluate if a asp.net middleware isn’t more suitable. I kept only validation as a MediatR behaviour. Mappping approach is nice, but you have to watch carefully the reflection hack and the implication of that autoimplemented IMapFrom interface (you have no implement interface suggestion on mapping method and no override). Tip: Keep and eye on the template repo, as new concerns are added from time to time. The version (for .net 3.1) with I started didn’t have Domain Events and not it does. Another Tip: Think and talk all the time on how to pull down logic into domain layer and value objects. Each achievement on this is worth. Talking about the adoption curve, our team was coming from a very crud like approach, the new concepts were not particularly easy to assimilate, especially due to the considerable amount of new stuff. I’m trying to include some DDD and testing concepts in a progressive way, assuming that some old-style code will be leaked into the project, and (ok, never) fixed later. I thinking that maybe I walked into my own trap, but we need to produce. One big (maybe the biggest for us) thing is EF, although is not specifically related to the architechture nor the template. Our team has a lot of xp on databases, so I kept a repository with Dapper up my sleeve, but I didn't have to use it for the moment. It took some time but people got used to query with EF. More complicated is the code first approach and migration handling. It’s hard to know the implications of each thing you do in your entities and configuration and maintain the schema without crash the migrations. But it’s rewarding. Right now I’m dribbling between my boss, ask me for the old development speed, and the project, begging me for more tests and a CI pipeline. I believe that is there (with CI) when we will have some more clear benefits in the middle term. In the long run, I expect lower maintenance costs and more confidence in what we put into production, a well as less “this was made by …, call him!”. If you have a team of committed people and time (figth for it!) to do technical meetings, code reviews (I am implementing them now, as I ends up convinced that they are absolutely necessary) and bosses capable of invest into the future, I keep recommending this approach. In the other hand, I’m sure if we were to skip the guidelines, take shortcuts over the architecture and let concerns leak through the layers, we would be facing a very complicated situation. If you walk into this, plese tell how it went. Regards
@espvp
@espvp 3 жыл бұрын
@@malehernandez1975 Thanks Alejandro! That was a very insightful overview of your experience with this. I may grab some approaches and patterns from this template for an upcoming project, though will not be able to start from the template itself. I will remember to post feedback if ever got something useful to add. Thanks again and good luck for you and your team. Regards.
@elan2199
@elan2199 2 жыл бұрын
@@malehernandez1975 What a detailed feedback. Thank you!!
@sotsch9280
@sotsch9280 3 жыл бұрын
This is simply amazing! it shows how easy it is to make architecture clean (in terms of uncle bobs definition) and maximal reusable
@smg53719
@smg53719 2 жыл бұрын
Best tech video I've watched in a long time. Perfect level of detail.
@MaJoBeatIt
@MaJoBeatIt 3 жыл бұрын
Best architecture presentation I have watched and understood.
@craigmunday3707
@craigmunday3707 3 жыл бұрын
Excellent talk and a really nice take away solution To me, clean architecture is best explained by making the distinction between compile time dependencies vs runtime dependencies. It helps explain why interfaces and implementations are in separate layers
@AbhishekSingh-ky4ud
@AbhishekSingh-ky4ud 2 жыл бұрын
Awesome!! Really loved the no fuss, simplistic, to the point explanation❤
@dmsanz_youtube
@dmsanz_youtube 3 жыл бұрын
It's a very good talk on how to achieve clean architecture, but I disagree with the definition of domain and application layers. I guess the author is not following DDD, but domain is domain whether or not DDD is followed. I don't think domain is the enterprise wide logic and types nor application layer contains business logic and types. If we follow DDD, the domain layer actually has the business logic, it represents the business ubiquitous language. All the business rules are there. All the important domain validations, the model itself, etc. It's not enterprise wide, it is the bounded context wide. The application layer has the orchestration of the use cases that delegate on domain layer to achieve state mutations. Command handlers for example. But it's a good presentation!
@brianwells990
@brianwells990 4 жыл бұрын
If this had been recorded in 2020, more than a few audience members would have fled the room when Jason kept coughing. Joking aside, this is a fabulous presentation. Thanks!
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
Haha, so true. I'm going to be presenting a bit from home so I can cough freely and people will just be glad not to be in the same room with me. 😄 Thanks for the feedback Brian! 😊
@brianwells990
@brianwells990 4 жыл бұрын
@@JasonTaylorDev Just out of curiosity... I'm implementing things gleaned from your presentation(s) (I see at least two, one with updated info)... and I found myself wanting to confirm the lifetime of your Validators. Quickly discovered I don't exactly know how your project hangs together, because I couldn't immediately figure out where Validators are created. It *seems* they are created as Transients... in IPipelineBehavior implementations? I was curious what about Validators (ones that don't use db connections, at any rate) would prevent them from being Singletons.
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
​@@brianwells990 No worries. The validators and the validation behaviour are wired-up within Application/DependencyInjection.cs. This contains an extension method to IServiceCollection and is invoked by WebUI/Startup.cs. The validation behaviour is invoked for all requests. The default for FluentValidation in ASP.NET Core is to register validators as transient, however in the past, they were in fact registered as singleton. You can learn more about that here; github.com/FluentValidation/FluentValidation/issues/814. I'm registering them as transient to be consistent with the default behaviour and since I want to inject services from time to time. As mentioned in the above issue, the initialisation cost is low, so this scope works well. You can still register them as singleton if you like, this is covered here; docs.fluentvalidation.net/en/latest/aspnet.html.
@lilee5187
@lilee5187 4 жыл бұрын
@@JasonTaylorDev Hi Jason, I can't find your GitHub page or twitter anymore.
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
@@lilee5187 sorry about that. You can find me here: github.com/jasontaylordev twitter.com/jasontaylordev
@agustinustheoo
@agustinustheoo 3 жыл бұрын
Love this solution, can't wait to apply it myself!
@zensic
@zensic Жыл бұрын
Thank you! Lots of new topics to look into!
@0xbitbybit
@0xbitbybit 2 жыл бұрын
Definitely needs to be more videos like this, you listening C# content creators? Show how things actually work in the real world, what the code looks like, so much better than just an explanation!
@abdulnaveed4984
@abdulnaveed4984 2 жыл бұрын
THIS IS A SAMPLE AMAZING , THANK YOU SO MUCH
@pajriaprilio6348
@pajriaprilio6348 3 жыл бұрын
Good presentation. Thank you !!!
@WahidRezgui
@WahidRezgui 3 жыл бұрын
Great video !! Many Thanks
@lucascc26
@lucascc26 3 жыл бұрын
Great stuff! Thanks for sharing
@dule88rs
@dule88rs 3 жыл бұрын
This was really great!
@cutelittlebirdie789
@cutelittlebirdie789 3 жыл бұрын
This is so educational plus his voice is so asmr-y
@michaelbui1939
@michaelbui1939 Жыл бұрын
Not sure if I agree with data transfer object (dto) depending on Domain Objects (do). DTO are a communication concern not a data storage concern.
@rustyshackleford6007
@rustyshackleford6007 11 ай бұрын
Yep
@sergiik2168
@sergiik2168 2 жыл бұрын
Look like experts thoughts about repository pattern are cut out from context... but anyway, when you use EF Core abstractions from application layer you are breaking The Dependency Rule. Also, your Infrastructure layer uses domain entities directly in DbContext, which might be okay for a really small (and useless) demo project, but will be bad in real development. Probably, most common real life example - many-to-many relations will looks differently for EF Core entities and for domain entities.
@w1tcher_550
@w1tcher_550 Жыл бұрын
looks good, to my regret, i can't find any architecture content in my native language, so this is really looks good
@christian.mar.garcia
@christian.mar.garcia 4 жыл бұрын
Very good talk, very informative. Thank you for providing the github repo.
@emekaegbuniwe7372
@emekaegbuniwe7372 3 жыл бұрын
do you have the link please?
@calancehong7908
@calancehong7908 3 жыл бұрын
@@emekaegbuniwe7372 here you go github.com/jasontaylordev/CleanArchitecture
@Miggleness
@Miggleness 3 жыл бұрын
The disadvantage of following clean architecture strictly are leaky abstractions and over abstraction. I personally prefer the simplicity of vertical slice architecture in JBogard's literature. Great talk on the topic. The template would be very helpful, too.
@milosmrdovic7233
@milosmrdovic7233 2 жыл бұрын
Well, this is not Clean Architecture as its primary design goals are not met. Leaky abstractions are not a feature of Clean Architecture but this particular implementation, which incorrectly abstracts certain layers. You can argue against abstractions, but it's a matter of using the right tool for the job - use it where it makes sense.
@johanBe75
@johanBe75 2 жыл бұрын
It so smart and secure! even i can´t start it from visual studio!!
@kevinvelasquez271
@kevinvelasquez271 4 жыл бұрын
I've been waiting on you to upload this amazing talk! Thank you very much!
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
Thanks Kevin! 😊
@mariomamalis
@mariomamalis 4 жыл бұрын
Pretty damn good!
@barsvelioglu2276
@barsvelioglu2276 4 жыл бұрын
I think CQRS makes things complicated. If the frequency of writing or reading is not very different, then there is little need to use CQRS. Also the read or write models should be quite different I think. Thanks for presentation.
@shreyasjejurkar1233
@shreyasjejurkar1233 4 жыл бұрын
Yes, you are right. You can swap the meditor + CQRS pattern with service pattern in Application layer if you would like to or if your domain does not contain any complex logic! 😇
@kunichiyawa1660
@kunichiyawa1660 2 жыл бұрын
@@shreyasjejurkar1233 that's what we did! We replaced cqrs with service pattern and thought it's much simpler than this one. But the idea still remains
@shreyasjejurkar1233
@shreyasjejurkar1233 2 жыл бұрын
@@kunichiyawa1660 yeah. CQRS is just one of the example on how we can implement Application layer!
@ashwanisingh3049
@ashwanisingh3049 4 жыл бұрын
Hi Jason Thanks a lot for this clip but I have one question here. How can I use this with MVC client . Currently I am not looking for SPA rather I am doing my project in .NET core razor pages. Can you give me some tips or any reference site. Thank you again !
@emreaka3965
@emreaka3965 Жыл бұрын
Thank you! Indeed.
@WahidRezgui
@WahidRezgui 3 жыл бұрын
Great videos, I have one question please : I tried to implement the clean architecture based on your template in UI side I created a WPF app and now I can’t figure out how to write handler to catch exception from the application layer those under common/exception
@yuvarajvelmuruganmudaliyar
@yuvarajvelmuruganmudaliyar Жыл бұрын
0:44 Domain represents the business and it's logic. Business logic which doesn't fit inside a domain is placed in domain service. Application layer contains use case's of the application.
@minimal4o
@minimal4o 4 жыл бұрын
@Jason Taylor, thank you for the nice example. I am only ambiguous with the following. I've seen plenty of code, even in frameworks, which relies on an exception being thrown by the validation. I've worked for a few people, who despised this approach and preferred to have the validation result being returned as an object. Needless to say, this is mostly due to the contextual switch of try-catching it. What are your thoughts about it?
@faseehashraf8688
@faseehashraf8688 4 жыл бұрын
Thanks man.
@joelmamedov404
@joelmamedov404 4 жыл бұрын
Good talk. Thank you. I believe validation (in your example is a data validation) should be at the domain/data layer. The required field is part of the domain schema construct..
@shreyasjejurkar1233
@shreyasjejurkar1233 4 жыл бұрын
Domain values are affected by command and queries, so validating those at first level will also be good. And also domain does not contain any logic of validation, those are just clean. Domain might be share across the other application and can have different requirements and validations that's why the validations are the part of application layer and not domain layer.
@FilipCordas
@FilipCordas 4 жыл бұрын
Yee this is how you 'abstract' your data layer. Since he didn't want a reference to entry framework to domain so that becomes good to keep in a different layer. Your database is 80% of your application and the whole we will just swap a layer and use a new database is impossible. For example try implementing unique constraint on cosmosdb. Sql does this out of the box but cosmosdb only allows uniqueness on a single partition. So if you put that unique constraint it's not going to work unless your partition is good. I saw many many hard to solve bugs when people switch from ef to ef core. I am still looking for someone that managed to do this with out major refactoring on a non todo app.
@shreyasjejurkar1233
@shreyasjejurkar1233 4 жыл бұрын
@@FilipCordas todo is just simple way to show real world scenarios, when you start building your next apps with this architecture, you will thank yourself by choosing this arch.
@FilipCordas
@FilipCordas 4 жыл бұрын
@@shreyasjejurkar1233 hey don't get me wrong a lot of the stuff here is good advice but changing the database is a myth
@shreyasjejurkar1233
@shreyasjejurkar1233 4 жыл бұрын
@@FilipCordas what do you mean by its, you meant changing database provider is hard with this type of arch?
@pinguincoder
@pinguincoder 3 жыл бұрын
One Thing I still dont get that by adding an extension method in the Application to register the Class and interface of the Infrastructure you need to add a reference from Application to infrastructure aswell so you have infrastructure depending in Application because of the interface and the startup Project depending on infrastructur because of the Service registration for DI. Which is kinda Bad... Since now somebody still can use the direct repo Implementation to connect to DB instead of using the interface. Is There any way around that?
@mariaevabaynosa747
@mariaevabaynosa747 3 жыл бұрын
Could someone please explain to me how domain.entities being used in persistent (configuration) layer without having to add a project reference from the domain layer?
@rafaszymanek455
@rafaszymanek455 2 жыл бұрын
Nice presentation, clean archtecture, clearly explained :) Nesting handlers in Query classes is a little bit messy in my opinion. You can create separate file for handler and put it in the same folder as Query class.
@Philinnor
@Philinnor 2 жыл бұрын
No fast navigation is vital, trying to find and having to click on your handlers gives me cancer. One should not always sacrifice ease maintainability for pseudo cleanliness.
@ivapmail
@ivapmail Жыл бұрын
Lots of food for thought
@Fuel16vt
@Fuel16vt 4 жыл бұрын
I do not understand why your application/service layer returns viewmodels. This makes the application dependant on the presentation layer. For example: A mobile phone app and a desktop app might have different data needs for presentation.
@DanteDeRuwe
@DanteDeRuwe 4 жыл бұрын
Good question. Also interested
@ajricherson1099
@ajricherson1099 3 жыл бұрын
My guess is that you could convert those viewmodels into application specific models later on in each consumer. The point of returning viewmodels is security; you wouldn't want to return certain properties from the database to each consumer.
@maxandriani
@maxandriani 3 жыл бұрын
@@ajricherson1099 He could return a Dto...
@milosmrdovic7233
@milosmrdovic7233 2 жыл бұрын
@Ivan Lapitski You are correct. Use cases should return generalized DTOs, not view models. Otherwise, your app layer depends on the UI.
@MegaNaeemraza
@MegaNaeemraza 3 жыл бұрын
Did you implement the Domain-Driven Design principle to achieve Clean Architecture?
@GG-uz8us
@GG-uz8us 2 жыл бұрын
This is really amazing template. However, most of the time (at least from my experience) domain and application are really the same, if so, isn't it a little bit over engineering to separate them?
@ammaralhabib6444
@ammaralhabib6444 Жыл бұрын
Hi Jason Taylor, I really appreciate this video, it is very helpful. However, I am confusing a little bit. At the beginning of the video, you mentioned that the infrastructure layer depends only on the Application. But when you explained the infrastructure, especially the AppDbContext, I saw there is a reference to Domain (ex: DbSet ), which is a cross border, isn't? I would appreciate if you have a time to reply to this question, because I could not find the answer.
@malikehsan147
@malikehsan147 3 жыл бұрын
How to target specific framework while creating this solution template?
@Potzakv20
@Potzakv20 3 жыл бұрын
Wonderfull!
@a_b_t_s
@a_b_t_s 2 жыл бұрын
where should the regular middlewares be added in this type of architecture?
@huntersMoon01
@huntersMoon01 3 жыл бұрын
I got question, if we infrastructure where all commands Queries should go as by naming convention 'Infrastructure' and all data related activities. DbContext, dataModel, Model Configuration then why we putting CQRS in Application! for me it does not make sense?
@mihaipanait2844
@mihaipanait2844 Жыл бұрын
The BeUniqueTitle sql validation in not correct in a concurrency scenario. Before the time you perform the validation and the time you save the entity, another entity with the same title might have been already inserted.
@sktbrddss
@sktbrddss 3 жыл бұрын
i'm visiting this 3rd time and now i realised that i would realy like to execute GOTO 2019 from title... 2020 blows
@borotaigor
@borotaigor 3 жыл бұрын
Nice one!!!!
@jsimsons
@jsimsons 4 жыл бұрын
​ @Jason Taylor Why is Core project dependent on view models? Why is it creating and returning them? It should be the responsibility of Presentation layer.
@sotsch9280
@sotsch9280 3 жыл бұрын
I agree with that, vm - implementation is concern of presentation - layer
@FatihKerimAktas
@FatihKerimAktas 4 жыл бұрын
How would you use automapper for a command, like creating a person, when working dtos. Let's say I have a collection of EmailsDTO's (public ICollection Emails { get; set; }) in CreatePersonCommand. How would this be used/saved in de Handle method (context) without creating a new collection (list) of Emails ?
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
Numerous approaches, but check out docs.automapper.org/en/stable/Reverse-Mapping-and-Unflattening.html
@ilovepandaypoe6056
@ilovepandaypoe6056 4 жыл бұрын
is there something wrong with the audio? i find it too soft.
@vladradu9966
@vladradu9966 2 жыл бұрын
I don't see how CQRS helps with modifying and maintaining. If the app is simple, it seems true. But if you move from controllers calling services which call other services to controllers sending events to be dispatched to handlers and those handlers calling services, it seems to me that complexity isn't decreasing. You have to modify both handlers and services if you change or add functionality. Is there an example of a big and complex application using CQRS? I really want to see how it works.
@ivapmail
@ivapmail Жыл бұрын
Do I understend correct that Query classes actually follow to Specification pattern?
@ranjithkumarchinnamuthusam2044
@ranjithkumarchinnamuthusam2044 Жыл бұрын
How to handle context switching? If I want to join more than one tables
@carlknox-robinson678
@carlknox-robinson678 2 жыл бұрын
I'm confused as to why the application layer has database commands - shouldn't this all be in the infrastructure layer?
@ghazanfarkhan3068
@ghazanfarkhan3068 4 жыл бұрын
Any example to changes infrastructure DB layer with MongoDB ?
@shreyasjejurkar1233
@shreyasjejurkar1233 4 жыл бұрын
You can just do by changing provider in infrastructure project provided you have installed supporting ef core package for mongodb
@bandaopsi
@bandaopsi 4 жыл бұрын
Only commands should be queued in the mediatr. Queries are read-only, should be listed from the repository only
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
Hey Andre. Interesting idea, but I think this approach might end up with rather bloated repositories. I think MediatR is really well suited to support both commands and queries. It's support for cross-cutting concerns with behaviours is awesome.
@bandaopsi
@bandaopsi 4 жыл бұрын
@@JasonTaylorDev You can use application services to access repositories.The idea of ​​cqrs is to keep writing completely apart from reading. Leaving asynchronous commands and synchronous readings
@shreyasjejurkar1233
@shreyasjejurkar1233 4 жыл бұрын
@@bandaopsi the thing is that it's not possible to wire up meditr behaviors with services because it does require IRequest. Behaviors like logging and query response cashing
@eliezerportillo7
@eliezerportillo7 4 жыл бұрын
What about Domain Services and Domain Specifications? Don't need them anymore?
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
I've not taken a DDD approach in this example, but for a sufficiently complex business domain I would. Either approach works well within this design.
@jayeshl5367
@jayeshl5367 2 жыл бұрын
Hello Jason, I am using "Clean architecture". Your blog helped me a lot to implement it. I want to add "log4net" in "clean architecture" Please help me. Thank you
@rishikeshsharma5691
@rishikeshsharma5691 4 жыл бұрын
While executing the Add-Migration AddOneTabel command on the project Infrastructure gets the exception "Unable to create an object of type 'ApplicationDbContext'. For the different patterns supported at design time, see go.microsoft.com/fwlink/?"linkid=851728" Please help! Thank You.
@rishikeshsharma5691
@rishikeshsharma5691 4 жыл бұрын
Anyone can suggest what I am doing wrong ?
@sebianadiliberto5522
@sebianadiliberto5522 4 жыл бұрын
Very good talk even if hard to follow because of the accent. I would not use fluentApi for validations but specifications called by application service, then just chain potential validations warnings/errors to return as metadata. That would improve re usability when checking on submissions ranges values etc.. or validate against the DB. It's possible to use reflection against the type submitted and build the tree of validations dynamically. Few bits here and there, for complex problems I would promote more domain factories, but loved the talk. Thank you
@renovatiofilms
@renovatiofilms 5 ай бұрын
min 19 why doesn't create the sample on the fly? where is the easy way??
@tomc2745
@tomc2745 3 жыл бұрын
I'm trying to learn and understand this architecture. The thing that bothers me is the number of classes that need to be created. There is something ying yang about being able to request an object, modify it, and send it back. Rather than request an object, format it, make changes, and then save it as some other class that doesn't even share an interface or base class. Am I crazy?
@Terszel
@Terszel 3 жыл бұрын
It depends on scalability of dev work. If you're expecting to have lots of engineers touching the codebase this kind of architecture makes sense because it reduces the mental overhead needed to implement new logic and features. This would be overkill for a small team that will remain small, and you likely wouldn't use this if you had an extremely large team (~1000s) that all worked in different languages because the ramp up time would not make sense. This is sensible for a large, strictly C# shop
@bramburn
@bramburn 2 жыл бұрын
is there any books that covers this?
@kudorgyozo
@kudorgyozo 2 жыл бұрын
What about events?
@angryrabbit7682
@angryrabbit7682 3 жыл бұрын
👍
@danielvelkov116
@danielvelkov116 3 жыл бұрын
32:37 exactly what I was thinking when using the repository pattern. If you use ef core it's the same thing. It's just that you have 1 layer for naming requests and that's it. Also Everytime you add a using statement which bloats and repeats everywhere so I am not so sure about that
@sergiik2168
@sergiik2168 2 жыл бұрын
Repository or not, but when you use EF Core abstractions from application layer you are breaking The Dependency Rule. This is not a Clean Architecture style
@milosmrdovic7233
@milosmrdovic7233 2 жыл бұрын
The repository pattern should completely abstract the entire persistence layer, not just the database as it's the case with EF. The presented solution tightly couples the application layer to the persistence library, a library that introduces breaking changes every few years. That's a horrible design decision if you're wanting your solution to last a decade.
@MikeSheen1972
@MikeSheen1972 4 жыл бұрын
Petty nit: at 19:52 you meant to add a property CurrentPage not CurrentSize.
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
Yep, you're right - thanks.
@MAHMOUDALI-jz6qc
@MAHMOUDALI-jz6qc 4 жыл бұрын
How can I control in Login and Registration flow internally ?! ,Thank you Jason
@denizozogul8760
@denizozogul8760 4 жыл бұрын
Repo : github.com/jasontaylordev/CleanArchitecture
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
If anyone is interested this is a follow-up talk that I recently released: kzbin.info/www/bejne/aIataKB3qauon9E
@omidahmadpour2535
@omidahmadpour2535 3 жыл бұрын
where is the business rule in this architecture? which layer?
@shustypl
@shustypl 3 жыл бұрын
In Domain Layer. Avoiding anemic entiities rly helps.
@lucasldossantos
@lucasldossantos Жыл бұрын
It's a nice presentation, but you can't call it Clean Architecture if you don't abstract persistence. Your application is still coupled to your database schema and to the limitations of the ORM.
@davidstephen7070
@davidstephen7070 Жыл бұрын
yeah, i agree. Infra assembly dependent on domain assembly.
@QuandarNl
@QuandarNl 2 жыл бұрын
This template is so full of bugs. Out of the box you get swagger errors. Can't scaffold any identity items. Nothing works properly.
@AddictedSoulsMusic
@AddictedSoulsMusic 3 жыл бұрын
this guy had corona when he did this right???... Otherwise its damn awesome!!!!
@miky97it
@miky97it 2 жыл бұрын
God if was a solution architect
@makahmed7130
@makahmed7130 4 жыл бұрын
Each time Jason is giving same talk )
@clashclan4739
@clashclan4739 Жыл бұрын
Honestly DDD will not make easy to understand the project. It add extra learning curve for freshers and who new to ddd
@AlfredoAguirre21
@AlfredoAguirre21 4 жыл бұрын
Is this supposed to be KISS? omfg XD
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
Hey Alfredo. The simplest approach to enterprise application development. 😛 But if you do have any questions feel free to reach out on the repo - github.com/jasontaylordev/CleanArchitecture/
@myview9923
@myview9923 3 жыл бұрын
Simple for stupid 😜
@renovatiofilms
@renovatiofilms 5 ай бұрын
well if it was easy he culd make a sample on the fly... always with this languages is the same... .net is a pain head
@ryanleemartin7758
@ryanleemartin7758 4 жыл бұрын
Good talk but I have a criticism around the idea of lasting software. I think there's a fallacy in the software world which is: "you can or even should write software that lasts 20+ years." It's a nice thought and perhaps a useful guiding principle but that's just not the world we live in anymore. This is just a beautiful lie we carry around to convince people and ourselves of the great value we're creating while we pretend the entire tech world doesn't completely shift under our feet in less time. There was an era where such things were true. That era is gone. Having said that, software should be effective and reliable for its lifetime
@srossab22
@srossab22 4 жыл бұрын
Google Maps is 15 years old! In 5 years do you think you will use it more or less?
@RS-he1mb
@RS-he1mb 2 жыл бұрын
CQRS, a specific pattern that should be used when useful... The masses: Let's use CQRS for ALL the things!
@_jfsanchez_
@_jfsanchez_ 4 жыл бұрын
... it is something so sad :( to see a man working on the Windows CMD terminal.
@JasonTaylorDev
@JasonTaylorDev 4 жыл бұрын
I've upgraded to the new Windows Terminal - github.com/microsoft/terminal ❤
@myview9923
@myview9923 3 жыл бұрын
You should try Linux 😜
@ryanleemartin7758
@ryanleemartin7758 4 жыл бұрын
When did Clean mean adding piles of layers. The software industry has lost its mind on this garbage. Think about how much of this due to the fact that we can't figure out how to properly reconcile object graphs and relational data. It's time to stop and think that maybe just maybe the entire approach of object relational mapping is just bonkers. I mean.. LOOK AT WHAT MUST BE DONE! I don't want to say I have a solution (*cough* functional programming *cough*) but this is absolute madness and how it's considered to be good practice baffles me. So. Much. Boilerplate and exposition. Do you not know the misery in which you live!? lol
@shreyasjejurkar1233
@shreyasjejurkar1233 4 жыл бұрын
Can you please talk with example, rather than shooting bullets in air? 🙄🙄
@ryanleemartin7758
@ryanleemartin7758 4 жыл бұрын
@@shreyasjejurkar1233 No. It's much easier to shoot bullets in the air. :)
@shreyasjejurkar1233
@shreyasjejurkar1233 4 жыл бұрын
@@ryanleemartin7758 keep going then!
@DanteDeRuwe
@DanteDeRuwe 4 жыл бұрын
When requirements change, you'll be happy you had a robust architecture from the start. Also, collaboration is way easier when everything is split up nicely
@damilola_adegunwa
@damilola_adegunwa 2 жыл бұрын
forcing developers into the pit of success 🤣
@Cal97g
@Cal97g 4 жыл бұрын
Surely asp.net and clean are completely at odds to eachother?
@ddrsdiego
@ddrsdiego 4 жыл бұрын
Why?
@Santizo66
@Santizo66 4 жыл бұрын
Non sense
@AlexDresko
@AlexDresko 4 жыл бұрын
Why?
@RobProuse
@RobProuse 4 жыл бұрын
Clearly you have not used C# or ASP.NET recently and are letting past biases color your judgement.
@brianwells990
@brianwells990 4 жыл бұрын
Russian troll?
@pakistanmerijan1212
@pakistanmerijan1212 4 жыл бұрын
The way he is coughing throughout the presentation disturbs me a lot at this time of the age ..
@tarquin161234
@tarquin161234 4 жыл бұрын
Don't know why people bother with all this nerdy "architecture" and "best practice" shiat. ASP.NET is a piece of piss, end of. Jsut stick all the code in your action methods, keep it simple, and job done.
@mohamedessam3657
@mohamedessam3657 2 жыл бұрын
How to target specific framework while creating this solution template?
Clean Architecture with ASP.NET Core with Steve "Ardalis" Smith (2020-06-01)
1:50:17
Пранк пошел не по плану…🥲
00:59
Саша Квашеная
Рет қаралды 6 МЛН
Finger Heart - Fancy Refill (Inside Out Animation)
00:30
FASH
Рет қаралды 28 МЛН
Brutally honest advice for new .NET Web Developers
7:19
Ed Andersen
Рет қаралды 113 М.
Clean Architecture with ASP.NET Core 3.0  - Jason Taylor - NDC Sydney 2019
1:02:30
Vertical Slice Architecture (Jimmy Bogard)
1:35:42
Tech Excellence
Рет қаралды 8 М.
Unleashing Clean Architecture in .NET 8: Exploring the Solution Template - Jason Taylor
1:02:55
.NET Core 3.1 MVC REST API - Full Course
3:27:48
Les Jackson
Рет қаралды 957 М.
"Good Enough" Architecture • Stefan Tilkov • GOTO 2019
41:41
GOTO Conferences
Рет қаралды 259 М.
НОВЫЕ ФЕЙК iPHONE 🤯 #iphone
0:37
ALSER kz
Рет қаралды 351 М.
Rate This Smartphone Cooler Set-up ⭐
0:10
Shakeuptech
Рет қаралды 6 МЛН