Severity Code Description Project File Line Suppression State Error The current .NET SDK does not support targeting .NET Core 2.2. Either target .NET Core 2.0 or lower, or use a version of the .NET SDK that supports .NET Core 2.2. Northwind.Domain C:\Program Files\dotnet\sdk\2.1.4\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.TargetFrameworkInference.targets 135
Good video. Another aspect i would like to see discussed, is the way projects are structured in terms of namespaces/folders. This is a structure organised by Layers. The other option would be to have organized by Feature.
Definitely +1 this. Is it just a matter of feature-foldering all the way down? If you're being strict about bounded contexts, do you need to split into specific projects for each all the way down? Also would love to see how this would work in a larger enterprise stack where you've got multiple consumers, e.g. lambdas, microservices, web ui, admin ui, etc. Does it make sense for them to share everything?
A few remarks: Handlers for commands and queries can be best placed as a nested class in the dto. That way both are always together and you can't accidentally remove one of the two.. Repositories are also useful when you use EF Core, but I come back to that one later. But if you're talking to Document databases (MongoDB, RavenDB) Identity Server, (Azure) Active Directory, Google services and other data sources, a repository is still a very important and a neccesary abstraction pattern. Unit of work is technically a database/MTS/DTC concept. Anemic data models are ALSO a leaky implementation of you're database model (i.e. does not work with document or LDAP databases) and a clear DDD violation because none of the (write/set) properties are encapsulated via methods. Usually automapper is used to map domain entities to (relational) ORM entities (and back). Repositories should not be used to perform logic on a entity. Logic for entity behavior should always reside in the entity (aggregate root) itself. Repositories should be used for fetching entities (either a specific one or perform the query on the actual data backend), update data (create/update) or delete data (if possible). For instance on many of my repositories expose an IQueryable interface based on the DTO (not the entity). With an IQueryable I can filter, order and project data based on the DTO and the repository can translate that expression tree to LINQ provider of the data backend. It is not hard to translate an expression tree of ProductDTO to a EF Core Linq expression tree. I don't write the LINQ provider itself, I only traverse down the expression tree and build a second IQueryable expression tree but now based on the Customer entity of EF Core instead of CustomerDTO. But I can also exchange it with the MongoDB Linq provider. Because for both EF and MongoDB I need to map CustomerDTO to the customer entity. When you show the usage of INotificationService in CreateCustomerCommandHandler you go from the core (application layer) to the outside layer. Inner layers should *NOT* have knowlegde about the outer layers. That is not allowed in 'onion' architectures. NorthwindContext is part of the persistance layer (outer most layer) and should not be accessible in core (domain/application). That is where the repository pattern comes in handy. You can define a ICustomerRepository on the application layer and the concrete implementation (for EF Core) in the persistence layer.. The problem with EF Core is that it currently only supports relational databases (they did promise also support for object/document databases).. MongoDB for instance is at this point not supported. And because you made NorthwindContext part of the core, you can't swap it out to work directly with the MongoDB Linq provider. You can actually, but not without changing code of the core for a change in the outer persistense layer.. This is my change for the persistance layer: public class MongoRegistry : ServiceRegistry { public MySqlRegistry() { AddTransient(); AddTransient(); AddTransient(); } } And instead of the EntityFrameworkCoreRegister I use MongoRegistry. All hail to the repository pattern ;-)
Awesome video! We are on the verge of building a enterprise application based on an existing database with loads of app-logic inside the SQL server. This will make my life a lot easier.
Fascinating concepts. Really flips some of my ways of thinking on end (a good thing :)). Definitely going to be looking into the source and the resources!
21:38 - weeeeeeell, if you have a reference to DbContext in your Core it means you reference Entity Framework which in turn kinda means that a Data Access element leaked into your Application/Domain layer. As far as I know, Entity Framework wasn't really all that popular a few years ago and who knows if it will be in 3 years from now on...
EF is far more flexible as you think of it, and DAL is almost a traditional layered architecture pattern, so if it worth it, people do, sometimes - don't, it depends, make things done a pure way or dirty way. Pure way always time-consuming, and no-goal, compared to quick and dirty DAL, with EF, so it really doesn't matter if smoething leaked or not, BAL
Nice video! I love seeing people talking about Clean. The only concern I have is this attachment with libraries. MediatR is completely against Clean Architecture. You have to embedded a library to your application + presentation layer, and everything became dependent of this library, you have to inherit from an external framework to implement your use case. The concept of using this library hurts Clean Architecture, where technology is a detail not part of the system. You don't need this library to make CQRS or CAP happen.
I just recognised you. I read Martin Fowlers clean arhitecture and then I stumbled upon github.com/ivanpaulovich/clean-architecture-manga/graphs/contributors. I like it a lot, real implementations for Martin's concepts. I must say about clean arhitecture I like when the framework isn't driving my design. Keeping domain model separate from persistence model is a huge thing. We are creating a new arhitecture for existing big ball of mud enterprise application. Going to have two separte application running side by side and sharing a database. Still using the same entity framework entities but repository acts like a anti corruption layer and I can change domain model without making changes to database structure.
@@s0psAA nice! I just had a small participation there, my friend Ivan is the real deal. I also have a version of Clean, but using CQRS, you can find it here! github.com/fals/cqrs-clean-eventual-consistency
Absolutely love this video. Not sure how I feel about having your Domain layer depend on Entity Framework though. I definitely get that you're treating the DBContext as a unit of work, and a DBSet as a repository, so you're abstracting away the persistence technology and would be able to switch DB Providers. However you're still tying yourself to Entity Framework in general. Maybe that makes sense for most applications, but it still rubs me the wrong way.
You're not alone here, many developers feel this way. If your goal is to have a abstraction in front of EF Core so that you are not tied to that framework, do so. It aligns much closer to the principles of clean architecture. Just ask yourself, what problem am I trying to solve? If it fits, use it. Happy coding!
Thanks, very useful for keep code clean and understable. (with minimal effort to understand this conventions over configuration techniques like Mediatr etc.)
Jason, In looking through your entity configurations, I see you use .HasColumnType("money") type for price/cost related properties, I've always used decimal(8,4) (I do a lot of commodity/currency trading, thus the 4 decimal places) any reason I should switch to money? I also see you use .HasColumnType("datetime") for dates. I read somewhere a while back to use datetime2, and have been using that since, any reason to switch back to just datetime?
Jason this is an awesome awesome presentation. The new era of code development is very exciting. As with any new paradigm, it is important to address the reality of legacy apps written in older c#/.net framework. I have a erp that integrates great plains via econnect. Rewriting the code from scratch is not viable. However the paradigm of clean architecture allows me to think about what would need to be done to migrate the code to a newer framework . Actually tackling some of these concerns in your incredibly well organized and delivered presentations would be a nice next step.
Revisiting this presentation after 3 years. Quick thoughts on Repository + Unit of Work pattern with EF Core. I agree that DbContext and DbSet basically implement the Unit of Work and Repository pattern respectively. I also agree that you are more or less not tied to a particular database system - the change is seamless. But you are still tied to the particular ORM. What if later I decide to replace Entity Framework and use Dapper let's say? It seems to me that following the philosophy of Clean Architecture, we should abstract the mechanism of data storing with an interface and use that in the Application Layer handlers. Thus the database system as well as the means of database access are abstracted. Also, since each handler deals with one use case only, it seems to me that it makes sense that the repository abstraction it works with should be responsible only for the particular persisting/querying operation that is needed by the application handler and nothing else. So fx if I have a CreateAccount handler it should use ICreateAccountRepository and not IAccountRepository. Any feedback is welcomed.
Nice speech. Repository and UoW is an opiniated topic. If you don't use it you have a direct dependency on EF inside your domain and you're going to inject implementation, that's doesn't match the IoC pattern. In the other case, as said in this presentation, you recreate something that is a DbContext... It's not really easy to choose between both :\
Absolutely right, as with many cases the real answer to the question is- it depends. There are many devs out there who would always say "use" or "don't use", both are wrong.
Well, like said in the talk, there are seasoned developers reasoning for and against either, and there are cases when one fits your needs better. There is no silver bullet, what is important is that you understand the *reasons* for abstracting it away or not abstracting it away so you can make an educated decision with regards to the situation at hand. However, in my opinion, this "injecting implementation is bad" is a terribly wrong general belief. I often hear people talking about it with reasons such as "you need to abstract your persistence away so one day you can replace your RDBMS with a NoSQL DB or something like that". This is a made up reason, the real reason why you abstract certain things away is so you can replace your dependencies *when testing*. And you can do that just fine with concrete classes as well as long as the methods you will want to mock are virtual, which they are in EF Core, even EF 6. Apart from when writing unit tests, are you really going to want that replacability? I think not, because the idea of "I will just be able to swap it out for a NoSQL or something" itself suggests that there is a big "maybe" - in other words, you don't know what your abstraction will need to be compatible with or even if it will ever have to be compatible with anything else other than what you have now. How are you going to write an abstraction that you know will be compatible whatever a framework from 10 years later will support if you don't even know what you are shooting at at the present? Besides that, should you really expect it will be that simple as writing a new data access class behind the same abstraction? I think you shouldn't, especially not like you will just replace a RDBMS provider with a NoSQL one because these are just so fundamentally different. For example, you have unique constraints in SQL, most NoSQL databases don't support that. You have DB sequences in most relational databases while you don't in most NoSQL ones along with countless other feature imparities in the other direction as well. There is a reason you choose one particular database for your app - of course, this is often guided by budget and for what the company already has license for but in a bit more ideal scenario, you choose one because you know that what you end up choosing provides some features what others don't. From then on, you have two choices: - you implement an abstraction which contains only the "smallest common denominator" of the features - in other words, which are common to more or less every storage you are likely to ever have to support (=feature loss, you choose the "best" but you prevent yourself from using all its bells and whistles - features that make it better for your scenario than the others), or - include that feature in your abstraction, from where on, you have a leaky one. Granted, a leaky abstraction is still an abstraction and can be used for at least testing, if for nothing else, but that is something that (in the case of EF Core at least) the vendor-provided API already promotes. So you are just doing extra work for no added value. Those are my 2 cents...
I think is a good approach to add this layer of abstraction but only to decouple the RDBMS, because there might be the time when the organization needs to move to a NoSQL DB, this will make that change just easier, you are right in the fact that SQL and NoSQL approaches are different, that is why you need this layer of abstraction, you can implement the NO SQL specifics behind it as well, without the pain of modify the rest of the system. Of course is just an opinion, good luck coding !
@@danielvillalba4457 "because there might be the time when the organization needs to move to a NoSQL DB" - I feel like this is a wrong premise. Moving to a NoSQL database is not a matter of application evolution, nor is it an inevitable step in any way. Starting out with a relational one and later on moving to a NoSQL is a sign that you've got your design wrong from the beginning. These solutions are very different, and they are used in different scenarios and they are used for a reason. It is totally wrong that a relational db will inevitably need to be replaced by a NoSQL solution because there are requirements which cannot be fulfilled by anything other than a relational database. What I was trying to say is that since they are used in different cases (and ideally, as a result of an educated decision as to their feasibility) there is no point in creating an abstraction which will hide the underlying database. This is because they are so different that you can add a function to the abstraction for one of them for which there simply does not exist a corresponding functionality in the other. A simple example is when you have a database sequence in your relational database and you incorporate that into your to-be abstraction. The concept of database sequences does not exist in most NoSQL solutions. Even if a similar functionality does exist, they might behave so differently that you'd need to alter them simply to accomodate anything else to make it fit the other solution from which point your abstraction no longer lives up to the promise "you won't have to change the consumer code". Example: you do a query over a relational database. You know that relational databases are immediately consistent so the concept of stale results does not exist here. Then, you do the same against a NoSQL one. Most NoSQL databases are eventually consistent, meaning that your query might return not up-to-date results. Typically you will want to include a flag that the results are stale so you can warn the user. Yes, you can include a constant true flag in the SQL implementation, but then your abstraction is leaky. The important thing to realize is that in order to use the functions which make one database better than the other you must incorporate those into your abstraction otherwise you won't be able to use it. Now you have an abstraction that is not really an abstraction as it is tied to a specific provider. If you then decide "then nothing provider-specific can be included in the abstraction" then what's the point of choosing a better, and probably more expensive solution over a poorer in functionality and cheaper one? The bottom line is that functionalities are very different and by the time you've explored all the differences and nuances between them you will have realized that the common denominator between them is basically simple CRUD operations. That is not even close to what you'll need in anything but a trivial application so you are only limiting yourself for no real added value. It is not a shame to embrace the functionality of your chosen provider to it's full extent. If future dictates that your requirements change, well, embrace that as well. It will likely happen so much later over the time you employ your first choice and use it to its full capability you will have saved much-much more time and effort and headache than if you went for a compromising solution about which you wasn't even sure you'd need in the first place. And if you did know you would need it then why not use that other solution from the start? Don't get me wrong, I'm not trying to argue and I respect opinions but you should always guide your decisions by asking yourself "What is the value of the solution I'm proposing?" rather than "Well, how can I make this be so generic that it will support any future requirements I cannot even imagine today even though I am not sure I'm even going to need it?".
@@balazsarva1991 glad to hear that you always have worked with a great architecture from the very beggining, for the rest of the real world out there is not the case for almost 99% of the times. I agree that moving from sql to no sql is not a very common scenario but definitelly a valid one (I had the experiencie) , or maybe move your DB servers from MS SQL Server to Oracle, once again there are some small tweaks that need to be donde, and you can easily do them as long as you follow the contracts as defined in the video. Basicslly if you said that this pattern is not necesary because you have to start with a nice and ckean architexture from the very beginning then Martín Fowler is talking shit all the time and there is no need of design patterns at all right? Enjoy your beatyfull and perfect dev life hahahahaha
As a junior developer I really hoped to see how MVC controllers are designed with this approach. With API controllers you C/R/U/D, but when it comes to UI, you need data from different tables/entites, some of it is just for display, some of it is used for persistence. I wanted to see how such complexity is to be dealt with.
Hi. Follow the same approach. Suggest MVC controller has multiple actions, each associated with a single command or query. Actions associated with queries have a primitive type or query type for input and return a view model (not entity). Actions associated with commands have a command type for input and return nothing or an identifier (if necessary). Happy coding.
21:34 There is a dependency injection to an Entity Framework DbContext. The Application Layer has a high dependency to the persistence Layer. I know this is addressed on 29:45, but still not a purely "clean" application layer.
@@InDieTasten Then there is no reason to have Persistence Layer at all. IMHO Layers should have no strong dependencies. EF Core has abstractions, but the goal of that to support multiple providers. The Application Layer has direct reference to EF Core dll, which is wrong. There are should be implementations of Unity Of Work/Repository.
Hi @Jason, before all thanks for the knowledge, several concepts I liked to see, It would be great to see how do you achieve the fact to decouple Application Layer from Persistence, I mean if I create an Abstractions for Persistency it would be in the Application Layer I guess, then implement those interfaces in the Persistency Layer ?? It would be great to include this approach in the solution. Thanks a lot, all the best!
You're very welcome. I'll try to include that in a future update. For the time being I recommend the following: 1) create interfaces for unit of work / repository in the Application layer, 2) implement these repositories in the Persistence layer, 3) ensure that Persistence is dependent on Application and not the other way around, 4) implement the specification pattern (deviq.com/specification-pattern/) as part of the repository, 5) check out the source code for eShopOnWeb github.com/dotnet-architecture/eShopOnWeb/tree/master/src - especially in regards to the repository and specification. Hope this helps - good luck!
This is the second time I am watching this video and I just decided to download the code. I have one doubt about dependencies, if anyone could help me out that would be great. Slides say Application layer should not depend on any other layer (just domain), but in the code I can see that Application is depending also on Persistence. What is the right thing about that dependency?
Hi Guys, I friend of mine suggested me this video about Clean Architecture because I support a project that follows the Clean Architecture Principles. I would like to give my feedback on this presentation and implementation. First of all, the way you introduce the Clean Architecture principles is very straightforward, transparent and objective. Congratulations! I have a few concerns on your implementation: 1) The soruce code is more a good implementation on top of Entity Framework and MediatR that Clean. What if I wanna change the repository to a JSON file? Do I need to wait for an EF provider? Your code is coupled to EF in the earlier stages, also this Anemic Classes in your Domain is the result on how Entity Framework dictates the implementation. 2) MediatR to reduce the coupling in UI is another framework and it is not Clean Architecture. First, Clean Architecture should be build on top of Hexagonal Architecture. In Hexagonal, the Tests are the first consumer of your application, and frameworks are left out of your use cases. Every library should be behind an interface that belongs to your application, not the opposite! One problem that I see in MediatR is the requirement to inherit from its libraries which in long term brings high coupling. I removed it from the projects I support. I am looking for the future updates!
Thanks for your feedback Ivan. We're discussing a the use of EF Core here; github.com/JasonGT/NorthwindTraders/issues/18. In relation to MediatR I am happy to keep that framework dependency. If I was to pull it out, I would just end up building another version of MediatR or just adding the MediatR source directly to my project. It's lightweight, has no dependencies of its own, and does its job well - so I feel it is a good fit. What problems did you face with MediatR that caused you to remove it completely? I see you have quite a few videos on this topic - I'll check them out so I can understand your point of view better. Thanks again.
@@JasonTaylorDev The problem with MediatR is the requirement to implement/inherit from their interfaces in the Application Layer. It goes against the Stable Dependecies Principle, because later you design many classes that uses Commands/CommandHandlers and these last ones are unstable. I wish MediatR have an way to declare the Commands/CommandHandlers explicitly through DI configuration. So, my humble suggestions are to improve your design are to move away frameworks like Dapper, MediatR, EF from Application layer and keep working on this awesome project!
Awesome presentation, been trying to get more into learning big picture architecture. Would it be possible to repeat questions asked from the audience before answering them in future presentations? I can kinda gather the questions from the answers but it would be helpful!
Great video, Thanks a lot. I have a question. Where does the building users by AspnetCore.Identity fits? how the User entity looks like in domain layer?
WOE!!! This is some pretty advance stuff that I've never seen before in my 10 year career as a developer! Where to start? Not sure I could ever obtain this level of competency or level of understanding to the point its second nature! What about building something as fast as possible just to make it work and then refactoring your project later into something like this? Do developers really start their project out in a domain-driven-design way? To me, that would be taking away so much focus from your goals in building out the architecture of a project than it helps with just making it work and then later refactoring it into an architecture such as this, right?
I had an scenario where in my Web API we used Entity Framework Core, but we needed to create Azure Functions but using Dapper. We had Repositories and the Application Layer use them through interfaces, so in the Azure Functions we did an implementation with Dapper and pure SQL queries but using the same Application Layer we did it with EntityFramework Core on the side of Web API. Without repositories can we achievethat? Great video!!
Thank you so much for this video. Honestly, I disagree with you regarding using mediator. Mediator acts here like service locator pattern which is considered anti pattern. There are many reasons for that, but the main reason is that now after using mediator when u look at controller constructors you don't even know what this controller dependencies. Therefore, if u wanna understand what this controlller do specially in complex business logic. You need to go to controller itself, then to action, and see what mediator is calling then go to see what this command query does. I hope I can hear your opinion about this. Thank you again.
Thanks for your feedback. There is a good discussion about this topic here; lostechies.com/jimmybogard/2015/01/20/integrating-mediatr-with-web-api/ (take a look at the comments).
I think using the repository pattern is very important, what happens when you decide to change ORM, maybe EntityFramework is no longer supported or does not meet your needs, or if your data does not come from one source? If you agree to use the repository pattern over EF, you will immediately see that you also need the unit of work.
Everything looks very nice and well structured. At the end when I saw how controllers look like using this approach kind of all came in place. I do wonder though why mapping in project is chosen to be as it is with expressions in the class over using automapper? Would love to know the concerns if there are any about this. Architecture is very clean
@QsenM thanks for your feedback. No problems with using AutoMapper. At a recent talk Jimmy (the author) recommended focusing on the AutoMapper Querable extensions and the ProjectTo method - docs.automapper.org/en/stable/Queryable-Extensions.html?highlight=ProjectTo. I'd also recommend checking out EF Core Query Types (docs.microsoft.com/en-us/ef/core/modeling/query-types).
@@JasonTaylorDev Thank you. I do use ProjectTo and AutoMapper config a lot for cleaning my service layers out of type dependencies. Looking forward for a next great presentation.
You might like to check out these two articles; msdn.microsoft.com/en-us/magazine/mt703432.aspx (Dapper) and msdn.microsoft.com/en-us/magazine/mt703432.aspx (EF Core Query Types).
Have a question about the persistence layer and Repository Pattern with Unit Of Work. In Robert C. Martin book he said, that we should not be dependent on a framework, he said "framework is a detail" (it's a chapter naming). So EF is a framework, and in the project, there is no some abstraction on it. So if I wanna change my EF to Dapper ORM? I need to implement some kind of repository anyway and replace all injected dbContexts with this repository abstraction. I think there is have to be some abstraction on frameworks, or not?
We did it with queries layer, it is simple IQuerible implementation, EF layer (persistence ) returns all in IQuerible, so later if we decide to swop to Dapper, it will be quite easy to just remove EF at all
Can you extend your idea with authentication in the application layer? I have been thinking how can I use the Identity with this approach but still do not see it clearly. So how would you check user roles to see what they can do? Would you use the controller authorize decorator? I would appreciate if you can update your code with a simple example on how to fill those View Model properties for permissions. By the way... awesome talk!!!
Thanks for the feedback! I will try to add authentication / authorisation to the solution in the coming weeks. In the meantime, take a look at this sample as it includes integration with ASP.NET Core Identity - github.com/dotnet-architecture/eShopOnWeb. If you're building single page apps, you might like to look at this post also - jasonwatmore.com/post/2018/06/26/aspnet-core-21-simple-api-for-authentication-registration-and-user-management.
Thanks for the talk. Interesting to see some of the clean principals applies to ASP.NET Core. One area I can't understand though, is you reference the NorthwindDbContext in Startup.cs as you normally would, but the WebApi project doesn't reference the Northwind.Persistence project directly. How is it referencing that type without build errors? Thanks!
Good question. The Northwind.WebUI references Northwind.Application which in turn references Northwind.Persistence. So no need for a direct reference to Persistence.
How do you implement authorization using mediatr request pipeline. Authorization can be dependent on roles and policies. How do we proceed with that? Thank you
Why would you separate the model, its validation and configuration? Now you have basically scattered the model definition all over the place e.g. if I want to add a new model I have to add at least 3 files. For complex validation scenarios the model might implement something like a validation interface so that everything is in one place.
It's my personal preference. With I split the solution by feature, such as shown here; github.com/JasonGT/NorthwindTraders/tree/master/Northwind.Application/Customers/Commands/CreateCustomer, having a three or four small files to manage that feature just feels cleaner to me. Of course, you should stick with what works for you and your team. Thanks!
Interesting talk. One concern, however, with the amount of logging you are doing. You are including the DTO as part of the log itself. What happens when that DTO contains sensitive information? Common security guidance is to never log sensitive data. GDPR regulations forbid the logging of any sensitive data.
If you're using Serilog as your logging framework, you can simply and effectively omit properties from the logs using the .Destructure method. Take a look at github.com/serilog/serilog/wiki/Structured-Data for some details. We use this to do exactly what you're questioning, removing sensitive information because of GDPR.
Its a pretty good architecture but i am not sure using/writing Command, Queries for each entity in Application Layer. It just doesn't make sense to me.
Good Speech...Interesting to watch this video Jason..I wanted some more descriptions on 'unit of work and repository pattern'. This portion i could not understand..Can you refer any link to understand more on this.
I was wondering if adding 'Persistence' project within 'Application' project references was not breaking the clean architecture rule, due to the diagram 1:40 shows up that the flow should be from 'Persistence' to 'Application' direction, not in the opposite direction. My understanding regarding that diagram was that 'Application' project should only refers to the 'Domain' project, none of other ones.
Yes, it does break that principle in that the Core layers are dependent on the EF Core framework. However it's worth noting that even so, the solution is not dependent on the database. It's a tradeoff - as with Architecture and Design - it always depends. Check out the discussion here; github.com/JasonGT/NorthwindTraders/issues/18. Thanks!
It's amazing thank you very much. i have only one question, could we avoid depend on persistence layer in application layer when injecting db context "we used a reference from persistence", or this is not considered as a dependency ??
Yes for sure, we can avoid it by a number of ways. Firstly, we can do so by using the Unit of Work and Repository patterns. To implement within this solution, I'd recommend adding unit of work and repository interfaces to the Application layer, and implementing these interfaces within the Persistence layer. Remove all references to the DbContext in the Application layer, instead utilising the new unit of work and repository interfaces. You can then correctly invert the dependency on persistence. This is the cleanest approach. Alternatively, you can create an INorthwindDbContext in the Application layer. The interface will include all DbSet properties and a SaveChanges method. Then add this interface to the NorthwindDbContext class in the Persistence layer. Finally, within the Applciation layer, replace all references to NorthwindDbContext with the interface INorthwindDbContext. Invert the dependency on persistence and add NuGet package reference to Microsoft.EntityFrameworkCore within the Application layer. This approach is good, as the dependency on Persistence is correctly inverted. It however is not quite so clean, as it means that the Application layer depends on Microsoft.EntityFrameworkCore (so a framework), but it doesn't depend on a database - such as SQL Server. Which option you will go for, whether it be the one demonstrated in the video or one of the two above, will depend entirely on your non-functional requirements. Good luck!
@@JasonTaylorDev Thank you so much Jason, both solutions are very good. I liked first one more, to use Iunit of work , to avoid depend on ef as you said. Thanks again your reply totally appreciated.
@@muhammedmmagdi - you're very welcome! Be sure to check out the following resources; deviq.com/repository-pattern and deviq.com/specification-pattern. Combing the repository with the specification pattern is a fantastic approach.
I thought in clean architecture, the domain layer doesn’t depend on any third party libraries? If your domain project reference MediatR, Fluent Validation or Automapper, can you still call it clean architecture? Isn't the "library and framework independent" rule violated when these libraries are used directly?
Good video, however I couldn't disagree more about data annotations. They are a perfect decorator that allows the entity to control it's own validation. This is a tenant of good OO programming.
Thanks Steve, appreciate the feedback. It sounds like data annotations are working well for you - that's great. Keep in mind that data annotations are no longer used by EF Core for entity validation, so you will need to trigger it manually. You can learn more here; docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/domain-model-layer-validations#use-validation-attributes-in-the-model-based-on-data-annotations.
I understood everything, it is amazing, but in real world some developers can not even understand the meaning of all that architecture, I have been working for almost 5 years as a back-end developer, and I still not found a company that has interest in spend time with a scenario like that, I also have tried to suggest but everyone is too lazy, =/
It helps to have a good lead developer who understands the architecture and can guide the team. Without that it can get a bit chaotic. There are some tools out there than can help to enforce conventions and coding style. You want to do what ever you can to force your developers into the "pit of success". Good luck!
21:50: Don't you have "illigal" infrastructure concerns in the Core layer? Shouldn't you be abstracting the dbContext into a repository or some other non-database dependent solution?
Watching this i started with my own attempt at Clean Architecture. (an app to fetch a meme from 9 gag and then display it back) github.com/metalglove/Ultrix Sofar i have the layers pretty good: -Application: Holds interfaces to interact with the Persistance and Infrastructure layers. -Domain Holds my Meme Entity. -Persistance EF for a repo to save memes -Infrastructure Fetches random memes from 9gag. -Presentation Presents the memes on the website. i also added a Mapping layer because i do not like the way you quietly reference the Persistance layer in the Presentation layer. Any feedback is appreciated. :)
A good start. I prefer to use CQRS in the application layer rather than services. Don't reference your repository inside the presentation layer. Only the application layer should reference the repository. Just reference commands or queries or services (if you prefer) contained within the application layer. Message me when your finished, love to check out the end result.
@@JasonTaylorDev It has been a while, but i have finished my project. I wanted to use CQRS but my teacher advised me to not make it too overkill, because I had a time shortage. So, I used services instead. If you are still interested in the result I would love the feedback! I will update the readme to have full instructions to run it. (edit: The readme is now updated)
@Jason really useful guidance, thank you! As a junior .net developer (with a background in PHP an interest in software architecture) I was spending the last few months in examining the options of a microservice architecture. If I'm not mistaking these guidelines are mainly applicable to monolith applications, right? What are in you opinion triggers to go from monolith to microservice. In other words if your in a team with mainly .net developers, is there any need to choose for microservice?
@Kim thanks for your feedback. These guidelines are applicable to both monolithic and microservices architecture. A monolithic architecture might be a good first choice, allowing you to clearly understand the domain and its bounded contexts. There are many reasons to chose a microservices architecture, for example - the ability scale out services independently, individual services can be easier to maintain, separate teams working on separate services, and so on. Check out .NET Architecture Guides for more information - www.microsoft.com/net/learn/dotnet/architecture-guides.
My only problem is that in controllers you always return Ok. What if there is an exception? What if a resource is not found? Is this handled somewhere else automatically or you only rely on messages?
Thanks for the question. Within the Application layer, any exceptions thrown will need to be handled by the client. This is where NotFound, Validation, and other exceptions are thrown. In this case the client is the Web API, and in the solution I have added a CustomExceptionFilter - github.com/JasonGT/NorthwindTraders/tree/master/Northwind.WebUI/Filters. It is responsible for catching the exceptions and turning them into 400s, 404s, and 500s. You can expand it to handle other types as needed.
Thanks for the wonderful presentation! When you covered the need to mock the system clock I got triggered because as my memory serves .NET Core already exposes a rather simple ISystemClock interface? Is there any reason to roll out your own? (Besides needing more than what MS provides with theirs? #curious)
Thanks, I didn't know about ISystemClock (docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.internal.isystemclock). Thinking out loud here; 1) this is easier then creating a new interface, 2) when creating an IDateTime interface, sometimes it's helpful to expose additional methods such as Year, Month, Day, and so on, 3) ISystemClock has a UtcNow method, if you wanted local it would be an additional call, 4) both serve to abstract the system clock. So no reason to roll your own, unless you want greater control.
Dear Jason, I want to know your opinion if I want to build flexible architecture to be able to change from Sql to NoSql database ? Thanks for your amazing solution.
First of all, thank you for the amazing video. I started developing a demo application of sorts to try this architecture, but I can't find the right way to do it in here. On my project, there is Products. This Products are grouped by different scenarios. Virtual Products and Shippable Products stored at same table with a boolean differentiating them. For Price calculation, the base formula is different, however the value of variables changes. So, GetOnlineProducts and GetShippableProducts needs to have a common method, that can be called by either of those. Where to place this common method? This method also will need to hit to a data source and get the latest variables.
You might like to look at inheritance with EF Core; docs.microsoft.com/en-us/ef/core/modeling/inheritance. You could create Product (base class), and Virtual Product (derived class). Product could have a base formula, and Virtual Product could override with a different formula. Generally speaking common logic should be pushed down from the Application layer into shared types or the Domain layer when dealing with enterprise logic. Good luck!
I thought in clean architecture, the domain layer doesn’t depend on any third party libraries? If your domain project reference MediatR, can you still call it clean architecture? Is MediatR a native library now? Please clarify. Thanks
I'm wondering exactly that too. Not just MediatR, most projects also include libraries like Fluent Validation and AutoMapper. Isn't the "library and framework independent" rule violated when these libraries are used directly?
Please can you 1) double check these instructions; github.com/JasonGT/NorthwindTraders and 2) raise an issue with specifics if it still doesn't work. Thank you.
Great question, apologies I don't have an example. Dependent on the requirements my approach would likely involve github.com/dotnet-state-machine/stateless. Let me know if you come across any good resources. Thanks!
Thank you for this nice structured presentation. I have a question since it wasn't covert on this presentation. In this architecture, where is going to be the best layer to handle authentication and authorization concerns. Can be implemented as another layer, dependent only to Application Layer?
One approach would be to add an interface to the Application layer with the relevant members (LogIn, LogOut, IsInRole, CurrentUser, ...), implement the interface within the Infrastructure layer using your preferred framework, e.g. ASP.NET Core Identity.
Jason, would it be possible to share some pointers regarding the use of Dapper instead of EF? I'm trying to build your architecture using Dapper and an existing database.
I've focused primarily on EF Core, I'll be looking at Query Types next. However, you could take a look at this repo; github.com/andrewabest/Eventador/tree/master/Eventador/Queries. It has a good example.
Nice but unfortunately there is one conflict or, say, a problem: As i see, the Application depends on Persistence, while he wanted to avoid this in the first slides! The solution for this design problem is to provide a Repository layer (Interface) encapsulating the EF DB context. The interface is to be then injected in the Application. -Hint: The Repository should provide generic methods: Public Interface IRepository {pulic TEntity SomeMethod ..}
@@JasonTaylorDev github.com/JasonGT/NorthwindTraders/issues/18#issuecomment-438549865 The Repository abstraction could/should be put in a Common Project, I.e. where things will be needed by both App and Persistence. Otherwise putting the abstraction in the App layer will means that the persistence project will not compile if App was not compiled first, but this would be ok if the Persistence is depending on App any way, which is the case here I think. In a curent project i work on I saw that Repo abstraction as well as all DTOs were put in a Common (Core) project so at least circular references are avoided... generally.
Hey Jason do you feel .Net as a whole framework or core is in a bad place now for webdev compared all the JS ecosystem ? it's like they are behind the curves now, nobody want to learn .Net there is more JS dev with React and all that I wanted your opinion about this.
Look at what's coming with Blazor. It has the potential to really change things. Javascript is a fruit of the devil pretty much. Blazor holds out the promise of .Net on the server and client side, without the limitations of Silverlight (having to install something first.) Plus it expands the Razor scheme so that you can do some fairly nice things. Everything running in the browser is a nose holding compromise. But, if you have to do it, getting rid of the disconnect between the server and the client's data representations helps keep down the stink more than most things. And being able to use a real language on the client as well of course. It's not officially fully baked yet, and course fate is fickle, but it's worth looking into.
No I don't think it's in a bad place. I'm building Angular / React / Vue applications on ASP .NET Core and Open API. I don't tend to build MVC applications anymore, I am very interested in Blazor.
yes but .Net is getting less popular by the days and the JS ecosystem keep growing... I am not sure if wasm or blazor will be popular or a thing etc look angular is less popular than React now, ppl don't like old stuffs, or when there is too many restrictions etc also the market could crash from too many JS coder we will see
@@JasonTaylorDev I've been helping someone on a fairly substantial application that was in Silverlight being ported to Blazor. It's a little frustrating right now because it's still a bit early in the process, so the tools can be a little tweaky. But, overall, it has a lot of promise, and it's a VAST improvement over javascript/typescript. You don't get away from HTML/CSS per se, but you can minimize it pretty well by using their pretty nice component scheme (possibly with some third party component library, though I'm more of a roll your own type.) Someone has implemented the functionality of bootstrap in blazor, so that's available to build on. Even at the application level though, it really pays to 'componentize' a lot of stuff because it gets rid of many things that would otherwise be annoying.
Hello. Hope you are good. In latest code, 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.
Don't you think you confused CQS (en.wikipedia.org/wiki/Command%E2%80%93query_separation) with CQRS(martinfowler.com/bliki/CQRS.html). I can see you using CQS when postinga product and having a get method for that posted product and not returning the product from the command itself. CQRS means you use two different models for queries and commands. I can see you using same domain model for both queries and commands. Both query and command invariants/concerns are still in a same model. This is something that I was confusing in the past also, whats your take on it? From Martins Flower article. At its heart is the notion that you can use a different model to update information than the model you use to read information.
Hi Siim - thanks for your feedback. In the sample app the write model is the commands and read model are the view models / DTOs. While the both use domain entities, neither use entities as input our output to the client. However going forward, I'll be making some changes. I want to avoid using entities in any queries. Instead I'll use EF Core Query Types or similar and map directly to the read models. This will mean I can skip mapping from entities to the read model, thereby avoiding projections, improving performance, and potentially simplifying the domain entities. With those changes in place, do you think we will be on the same page? Please share your thoughts.
Thanks for your thoughts. Keeping domain entities concerns only for invariants needed be to kept in writes and not reading from domain entities for reporting concerns. That's about it yes. What I have been thought of doing, is at the persistence/infrasturcture layer you have your entity framework entities/persitence model and in core layer you have domain model, which reflects the needs of writes, you use a repository which returns domain model aggregrate mapped from persistence model entities but it adds a layer of complexity and I'm not sure it's worth it, for reads you can use persistence model directly, which reflects more of a real database structue and you even have a possibility to write a sql statement for poor peforming enitity framework queries in read stack, which skips the domain model layer and goes straight for the data store. Here we can see separate domain model and persistence model. github.com/ivanpaulovich/clean-architecture-manga/graphs/contributors. But domain model is still used for reads.
