There are two fundamental issues that are often overlooked in these simplified clean architecture templates. First, UI depends on infrastructure. That dependency is usually not visible in charts for whatever reason, but it is there regardless. Secondly, the template uses core entities within DbContext in infrastructure. Now your database structure depends on domain entities. Those will evolve and your database breaks. Keeping database and domain entities separate is very important. I have used clean architecture for sometime, but in my model the core is split further into domain and application layers.
I agree about splitting the entity models and domain models. However this would be less necessary if you use something like EFCore migrations to ensure your DB is always updated. Although I've never been a fan of this approach, it feels fragile.
@@cheesypufs I haven't heard anyone using EF migrations in production and suggest nobody to do it. DBAs will not be happy. In critical systems database changes require review before apply. Keeping them in pure SQL is the cleanest approach. DbUp has been a great choice. The main issue with EF here is that it is too easy to spread database details everywhere. With clean architecture, only infrastructure layer should be responsible for database concerns. If there is only one entity through the application then everything depends on everything. Mapping objects is the necessary evil to keep consistency.
@@cheesypufs The main issue when using the same entity for both the domain and the db, is that you might end up in a situation where the structure or limitations of the database, also limits the way you build you domain. A database is an implementation detail, and should in no way govern the way you build your domain model.
Exactly! I have the same exact view. I use a mix of Clean Architecture and Vertical Slice Architecture (Jimmy Bogard). There are many videos on this from Jason Taylor such as this: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-dK4Yb6-LxAk.html Basically all the logic is in the Architecture layer either in MediatR commands or Queries. The Application Layer and the Domain Layer combined make up the Core. The Domain Layer does not have logic for the most part. I have always found it hard to accept how putting logic in your Domain Entities is recommended. Other than the basic logic that you can put there (such as date range validations etc), we typically work with very complex logic in our applications and our Entities are used in different ways across the system. Another point where I agree with you is that no matter how much we can say we can swap out database technologies it is not easy to do. You cannot easily go from SQL and EF Core to CosmosDB without changing a lot of code! Again if your system is as simple as each Entity can save itself bla bla bla and thats it maybe you could do it with minimum coding. But that is not realistic. I have EF Core Queries that span entities and are highly complex. Good luck rewritting all that using a different technology easily!
@@Greenthum6 EF Core migrations do not need to be automatically applied to production. You can generate a SQL script from the migration and have your DBA's review and approve before you run it.
| Links from the end of the video | ::Clean Architecture Template:: github.com/ardalis/CleanArchitecture ::eShopOnWeb:: github.com/dotnet-architecture/eShopOnWeb ::Architect Modern Apps with ASP.NET Core and Azure eBook:: dotnet.microsoft.com/learn/web/aspnet-architecture
Clean Architecture Template: github.com/ardalis/CleanArchitecture eShopOnWeb Sample: github.com/dotnet-architecture/eShopOnWeb Architect Modern Apps with ASP.NET Core and Azure eBook: dotnet.microsoft.com/learn/aspnet/architecture
Thank you Smith for great explanation, it's been a great help with Clean Architecture.I understand a bit better now where and how these things are handled.
It's purely a way of sharing (high level, abstract) code between apps. If every app uses the same guard clause extensions or value object base class, or exception base class, this provides a better tool than copy-paste or sharing the same source files for achieving this reuse.
That's very good question. I suggest that you use standard .NET authentication and authorization and implement Policies that are implemented by calling interfaces in the Domain/Core, probably with help for example a user database from Infrastructure.
I have learnt from experience, the application/business needs should help drive the architecture and not the other way round. So for example in the industry we do say let’s make sure we have clean architecture so that we can focus the business needs rather than fighting the technology as the application grows. This has merit and is correct, but is too late in the process. Understanding the business need in a ‘clean’ manner will help getting the right architecture in place, which in turn then helps us focus on the business and all that good stuff.
In a different tutorial, I heard that all of MVC in a Core project was the presentation layer and that business logic should be coded in a a class library in a different project. In this tutorial (if I've understood it correctly) the presentation layer and business logic are within the Core project. At time 7:51, it states, "Model all business rules and entities in the Core project." Perhaps some further explanation can clarify this for me.
if you have constants in a class Roles such as "Admin", "DemonUser", etc and you use it in all layers, where would you put this class? and the same as helpers like PaginationHelper to calculate Skip and TotalPages
Год назад
Constants to the Core project. PaginationHelper to the project where your UI lives.
Any and every company can manage the code as they want and according to in-house convenience standards - this is just another shuffle of someone's ambition or corporate idea that is not necessarily as good as they think
Why is there never an acknowledgement that in order to make "clean" architecture, you introduce massive amounts of complexity? Having to learn all the new terminology for stuff like value objects, domain events, validators, custom guards, etc. and figure out how to structure it all is no mean feat, and is a lot harder and less intuitive that just creating an n-tier application, to the point where an n-tier application is probably the best choice for anything but huge projects. 21:20 Composition root in the web project. I've noticed this before. So much for "clean architecture" stopping the UI from referencing infrastructure; it has the composition root. It has to reference everything!
"It's too complex!" but also "You should have added yet another project for composition root!" It's a tradeoff. Yes, you certainly *can* put all the DI/composition root logic into another project, but that only adds to the complexity without adding much value. You can certainly do that if it makes sense for your app.
This is one way of achieving clean architecture, this is mostly OO based, however in my view there is a much simpler way, Please see Domain Modelling made functional by Scott Wlaschin and thank me later. Everything in there can be done in any language and especially c#. The main difference is it is better not to include any IO related logic (DB, API, email sender, etc.) in the core domain layer as much as possible, even the interfaces
@@steve-ardalis-smith I guess, regardless of the paradigm, the concept is still the same, it is better to avoid IO in the domain layer as much as possible, also IMHO c# is an hybrid language these days, not just OO
26:40 - I don't get the advantage of separating the specification from the repository, is it the possibility of reusing specifications over different repositories?
Great talk, it would be nice if you put a QR code next to each link in the presentation, you don't see anytihing in the description of the video in youtube about links in the current presentation, sometimes links are so large
You say Core shouldn't have dependencies beyond shared kernel, but to implement specifications in the core project, you then have a dependency on a nugget package that provides specification abstraction, right? I realize it's a bit of give and take, but how would you navigate that decision in a new project?
This is a common question and sorry I didn't cover it better in the video. If you have pure code dependencies in Core or Shared Kernel, you can include them either directly within the project(s) or as NuGet references. Examples of pure code dependencies would be things like guard clauses, specifications, repository abstractions (not implementations, typically), fluent validations, etc. Basically, any dependency that simply runs in process and doesn't talk to external infrastructure concerns should be fair game.
@@steve-ardalis-smith I think Evaldas has a good point here as your specifications do have implicit knowledge of the underlying infrastructure. In your example project ProjectByIdWithItemsSpec uses the extension method Include from your Specification nuget. Use of this is obviously motivated by the knowledge EF is being used as the ORM. Of course IQueryable isn't a perfect abstraction and something like this isn't easy to reconcile with Clean Architecture, so definitely some give and take.
@@michaelvman It's true my Specification abstraction includes support for a .Include which can then be mapped to an EF/EF Core .Include, I'll grant that. But it's not specifically coupled to either of those frameworks (in that package - there are separate packages that are specific to EF/EF Core), and the use of .Include might be applied to other stores as well (imagine an OData backend or GraphQL building out an object graph, etc.). So, yes, I did purposefully choose to include features in my abstraction that easily mapped to my (current) implementation (because why make it hard?), but that doesn't mean I'm tied to the implementation.
@@steve-ardalis-smith I think you hit the nail on the head, why make it difficult and that's why there is some give and take. And I agree you're not coupling your specifications to a specific data store. All I'm suggesting is it's impossible for your business logic to be 100% ignorant of infrastructure concerns which is what Clean Architecture tries to aim for. Your Specification nuget allows you to use EF/OData/GraphQL features without directly coupling your business logic to those frameworks but you're still implicitly aware of how they expect to work and that's the compromise, albeit not a big one. I would be curious how elegantly specifications could be implemented when working with a data store that didn't use a LINQ interface. I'm guessing it wouldn't be possible and the heavy lifting would need to be done by a repository class. Anyway really like what you've done here and think I will try to use it as a starting point for my next project. Also very keen to give API Endpoints a spin, looks like a very promising approach.
@@michaelvman It is true that the LINQ-based Specification package I use (and maintain) works best with ORMs that support LINQ well. There have been efforts to apply it to Dapper and CosmosDB, for instance, that have met with limited success. The Specification *pattern* can still work with such back end stores and tools, but its implementation may need to change (for instance, if using Dapper, your specifications will likely contain raw SQL in them).
Hi, Please explain how the architecture changes when the database first approach is being followed. I didn't find much information about it as I need to implement Clean architecture with the existing database model. Please explain.
@@activoutdavid Yes, exactly. The db first entities would need to live in an infrastructure project, and you would map to/from them, ideally. It may not be worth the effort, though...
Ty for video, i am not sure why if i search information about thisi find difefrent info on all sites. For example in this site we can see in the structure core, and uses cases but the most common structure is application and domain. I don't understand why microsoft don´t have a profesional template and maybe with examples and important thinks.
"It depends". Sometimes it's really helpful to have DTOs in the Core project so everything can use them. However, most of the time these DTOs are only really used by some specific service, and aren't really a part of the "domain model". As such, they usually belong in the Web or Infrastructure project, or sometimes in a separate project (or nuget package) that these projects both reference. In that case it's usually a good idea to keep that project/package small and focused just on DTOs used for a specific purpose.
Just downloaded your template, a few questions: Why do we import the infrastructure project and not the Core project in the Web project ? Also how can we call the IToDoItemSearchService interface from Web if it is defined in Core and we don't import that project in Web ? Sorry for the confusing phrasing 😅
i think i understand now. We do import Infrastructure because we need to add the implementations to the dependency injection container and that would be impossible without importing the project in which the implementations are. Also we import Core, it's just not appearing in the dependencies tab in my project, but we're making "using ..... core" in some pages so yeah
I don't understand something. I pulled the sample solution and see the Web project has no reference to the Core project, while it has a reference to the Infrastructure project. This not what stated in the video. In the video it's said that both Infrastructure and Web projects should talk through Core project indirectly
I think realistically it not possible to simply replace the DB without changing Domain Service logic. With proposed clean architecture the EntityFramework is now abstracted but ApplicationCore is now depend on `Ardalis.Specification` which is just a wrapper around EF and exposes EF's extension methods via Specification. For example Include(), AsNoTracking() etc which may not be suitable for different database. So if you change DB, you most probably have to change specifications and that means domain service as well.
As Steve mentioned, Ardalis.Specification is one of his own projects, and most Clean Architecture implementations probably don't have it unless they use his Clean Architecture template... :)
ls this architecture good for microservices? please respond anyone who have used it or can provide a best link for that purpose. Thanking you in advance..
So, if i have to implement a TokenService that has external dependencies like microsoft jwt packages, for exemple. My question is: Will it go on infrastructure?
If the tokens is used in Infrastructure for calling an API then the TokenService also belongs in Infrastructure. Tokens are probably not part of the Domain/Core.
For complex problem give simple solution. I have seen in the name of ddd/onion/hexagonal architecture ppls tends to makes project complex to work and modify
regarding the diagram at 6:44 and how everyone says dependencies should flow towards the core project, doesn't the core project have to import the infrastructure project? Are y'all saying it's not dependent on it simply because the interfaces for the services and models are defined in in the core project?
@@yuvarajvelmuruganmudaliyar Correct. It uses the Dependency Inversion Principle such that interfaces are defined in Core/Domain project but implementations are in Infrastructure project.
@@activoutdavid How about If we want to host on azure. Few are Azure Function and Rest api then are we going to publish separate in projects and host it? is it so ?
why is this not called Domain Driven Design with asp.NET Core 6? I m new to all these and it's really hard to understand what's clean architecture and what's DDD.
1. Why use custom exceptions if we can propagate Error result from operations? The problem I see with exception, that flow is a bit implicit, and sometimes it's not very easy to properly handle such exceptions. As in different places same exception could mean different things from application perspective. As an example: throw custom exception in entity constructor, have a generic handler, which catches it and maps to 400 response, which sounds not so bad, when user tries to create that entity. But, what if that exception is going to be thrown when entity is being de-serialized from cosmos, for some other operation on it (corrupted data in db)? User will get 400, when 500 should be returned. 2. Not sure I understand, why do we need Repository Interfaces in domain layer? Why can't we have them in Infrastructure layer? We're anyway going to have some kind of application layer (in your case UI project), which will glue Domain and Infra layers together. Don't we? 3. Is it real the case, that Domain layer is completely independent from DB structure? As from my experience, it was pretty hard to achieve this due to some ORM limitations or similar. Might be, I was doing something wrong. 4. You mentioned that Core project is good for Validators like fluent validation. Do you use fluent validation in your domain model? As if it's about request DTOs, then it seems more like application layer concern, isn't it? Similar question for specifications - should domain layer care about queries? Why not put them into application layer close to appropriate use-cases?
1. Exceptions should be for exceptional cases. If you let a Cosmos exception propagate from Infrastructure, then you can't catch it in Web or Core because they don't know what Cosmos is. But if you wrap it in a "CorruptDataException" then you can catch it in Web and return a 500 :) 2. The Web layer should not know anyhing about the Infrastructure layer. It only depends on it to setup dependency injection. So any interfaces that are used by both Web and Infrastructure must be in the Core project. 3. Yes, if you work with clean architecture you create pure domain entities and only the Infrastructure project knows what ORM you are using and converts to and from the domain entities. But you could decide to let it leak a bit into Core in your application :) 4. If you think about it, validation is actually business logic.
I have a question, I am developing 3 microservices which is part of an application. There is a situation we use common functionalities acroess each project/layers. For example Exception handling and Entities can be used in multiple microservices. My question is where can we keep this common libraries in Clean architecture?. Do we need to have another layer that hold only common functionalities?. if we are going to have separate library then CORE, API, INFRA all layer may depend on the common library.
Try to reduce dependencies if you can so that each microservice can be deployed as independently as possible. I think that if you have the same entities in multiple services you should consider merging the services or slicing them differently so that they don't need to share entities. For example do not share a single database between multiple microservices. Or maybe you can actually just copy shared classes between projects.
@@nateg247 I am not sure if Functions should be seen as microservices, and thus your functions have to communicate with each other. Which seems silly. Instead of having the data access in the stomach of your application. Was thinking using MediatR, and simply inject MediatR into the Functions projects. Is this doable?
@@mart0347 But doing it this way, my Functions project will have a reference to my Application project, which will be a DLL with all my functions. A single Azure Function is meant to represent one controller in traditional api right? So I might have a Product Functions project, which have get/post/delete/put methods for Products right?
Ideally business logic lives in Core/Domain project. Web API gets to it via Application Services or by sending messages (Commands, Queries) via MediatR which are handled in an Application or UseCases project. The application services/handlers use the domain model types along with persistence abstractions to do the work and persist any state changes.
The IHostedService or the BackgroundService are implemented either in the Web or the Infrastructure project depending on the circumstances, but that implementation can then use domain logic in Core.
What do you do when you have items in your domain that depend on Identity Users? For instance, an e-Shop may have an Order table with a reference to the User Id that placed the order. If I want to view all of the orders for a single user that works just fine *var orders = await context.Orders.Where(x => x.UserId = 10).ToListAsync()*. However, if I want to show a list of orders with associated user details (name, email, etc), all of a sudden I have 1 + N queries because the Identity User is in the Infrastructure class and our other entities cannot reference it. For instance, we cannot do _var orders = await context.Orders.Include(x => x.User).Where(x => x.User.LastName = "Anderson")_ because introducing User would create a circular dependency between the Domain and Infrastructure layers.
You can not in any way depend on Identity User in Infrastructure from Core. You would need to have an Interface in Core representing the Identity and let Infrastructure implementation map and inject into Core. You could then replace your Identity system completely, as long as the new system can map to and honor the Interface of Identity in Core. This is the whole point, and where the cleaness comes from.
For raw queries I would typically avoid trying to use the domain model (which is built for mutations/updates) and instead just execute a database query directly. In many cases the identity information will be on a separate database or somewhere else entirely (for instance, Okta, Azure Entra, etc) so it may make sense to have a local *materialized view* of the user information you wish to display, which is periodically updated from the actual source.
The topic's architecture as I see it: let's have a big monolith in the center and surround it with some helper projects that will help it work somehow.
If you think a domain model with no dependencies on UI or data or other infrastructure is "a big monolith" then I could see how you might arrive at this conclusion. However, a domain model is, in fact, just a class library, not a monolith.
The examples of going with Clean in the beginning are just examples of general bad architecture or don't give you much. For example, Business Logic in the DB is frowned upon by all modern architecture approaches, no?
@@activoutdavid Yes, just for convenience. You can move composition root to another project if it really bugs you or you need to keep that separation "pure".
I totally disagree with aggregate root concept. There can be multiple scenarios i just have to crud on depended entity like order details without a need of aggregate root. Then why forcing it in the name of ddd
I use Clean architecture for my project, it is a little bit different though and even less depend on each layer. However using Value Objects is a real pain in the ass. First of all if you create your domain model and use it as main entity you can only guarantee that your value objects will be validated during Insert/Update requests from front-end. If you are trying to build your domain entity from external dependency or even from database request you may not guarantee that your Value Object will match the data that you got and it will break with validation. If external service that you are relying on return you something that you are not expecting, your application will fail on the stage of building that Value Objects
I think that in this case you should have a separate entity (call it DTO or API Model if you want) in Infrastructure without the value objects, and then you write code to map from the infrastructure entity to the domain entity and handle validation errors.
Your database and related should be a separate solution and a microservice else its not reusable . Now only your web app can call it. If I want a mobile app and thats wants to call the same dal then. Should I reinvent wheel again, wasting companies time for redoing whatever we did to build those db related things.
