I actually love how the Authentication is done Here. I have a quite similar Solution Template where much more things are Automated, especially the repository with caching, but authentication is a Part i am missing currently.
Hello Ami, it's great to have you back man. Just to be sure and for the sake of other viewers who will be watching this, the step involving the conversion of incoming requests into commands or queries does not necessarily imply the usage of the CQRS architectural pattern. Does it?
nice video, I have a question, if I have some azure durable functions with service bus triggers that handle business processes, where would you locate them?
Thanks, What do you think about using the domain models directly as the database entities or creating a persistence model for the database and then mapping them back and forth between domain to db entity and vice versa? I saw it as a challenge in real-world apps when having a complicated domain entity to be used directly as a database entity, at the same time, the mapping between domain models/persistence models also a challenge sometimes
Configuring the mapping between domain objects and the database is very flexible with EF Core. Personally, I dislike creating and maintaining another set set of persistence models.
Great template! Very close to Jason Taylor's with a few tweaks. One thing I'm surprised about the sample code is the Amichai allows Entities to be created in an invalid state. I can create a Reminder with a NULL text field, or a user with NULL first, last, and email. Obviously not an issue with the template, just an observation of the sample code.
Yep our templates have many similarities and I reused a few of his great ideas. Regarding entity construction, you can definitely re-validate the validations done early up stream if you think it adds value to your project/team.
Hey Amichai, I am having a lot of trouble trying to deploy this demo on K8s. Can you give a couple of tips? I am just trying to create an image based on your docker file but it is not working. I want to show my boss that this should be how to work properly. But still, no luck deploying
Help. My authorization not working. Did anyone has same issue ?I implementing IAuthorizable on one of the request and added Authorize attribute. I did register openbehaviour Authorization. What am I missing. IAuthorizable should be added somewhere ?
Logic in the domain ? I though that the logic was suposed to be in the application layer, can you please give me a insight brother? Thank you and sorry for the poor english. Im trying to improve it.
Nice one Amichai. I review such templates. Heads up: I noticed the short name clashes with Steve "Ardalis" Smith's template (clean-arch), so they don't work on the same machine in parallel unless you specify the full name. I'm especially interested in how you handle repository querying/specifications; Ardalis' Specifications library being on my lookout. I'll give a proper review after trying this out in use cases
Can you provide a quick comment on why you are seperating the API requests and responses in an other class lib.? It looks neat but is it the only reason?
We came up with an almost identical project arrangement in a new solution recently. I remember a lot of discussion around having separate Domain and Application project layers. We ended up having a single project for domain and application because it didn’t seem like having two added much value. Obviously every project has different needs, but when do you think it makes sense to truly separate the Domain from Application?
I think the commands and everything else should only be on the application layer since the domain does not need to be concerned about that. The domain should be only concerned about business rules.
Both are good approaches, and there are multiple templates that have a single project (usually named "core") for both the Application and Domain logic. Personally, I much prefer the separation. As Alisson said, the domain should contain the business logic and rules, while the application layer is just the orchestrator of the various domain objects and services. The project separation forces this separation of concerns and limits the domain layer from having access to all the various application layer interfaces
Makes sense. For our solution, the “domain” is largely dumb models for state and business logic Action (or “service”) classes. But if CQRS or DDD come into the picture, I can see some value in having separate projects
Very cool and organized structure 👍, I will check it in my next projects. Could you please tell me what this tool that you used to highlight and write on screen, I like it.
I noticed that the logic of the commands is in the domain class User (e.g., DismissReminder). I'm a little confused now, isn't the application's layer job to handle the logic? Why do we have that in the domain layer instead?
No. Taking the method you gave as an example: public ErrorOr DismissReminder(Guid reminderId) { if (Subscription == Subscription.Canceled) { return Error.NotFound(description: "Subscription not found"); } if (!_reminderIds.Contains(reminderId)) { return Error.NotFound(description: "Reminder not found"); } if (_dismissedReminderIds.Contains(reminderId)) { return Error.Conflict(description: "Reminder already dismissed"); } _dismissedReminderIds.Add(reminderId); _domainEvents.Add(new ReminderDismissedEvent(reminderId)); return Result.Success; } The application layer's responsibility is to orchestrate the domain objects (i.e. fetch the user domain object from the database and invoking the DismissReminder method). The actual decision if the reminder can be dismissed, is the responsibility of the domain. All the various actions that change the underlying state of domain objects is considered domain logic and is encapsulated inside the domain objects or services.
@@amantinband Thanks, that cleared some of the confusion regarding the role of the application layer. I still have some concerns that putting the logic inside the domain layer might cause some issues (for instance, what if we needed to access a service using dependency injection?)
Authentication is done using the built in middleware. Authorization is done via the mediatr middleware, and there is a mapping between the ErrorOr.Unauthorized error type to the Forbidden status code in the base controller
Just one question, I saw that the permission goes in the claims, when the project scales this could be a problem because it could end up with too many permissions, slowing down all requests because the token is very large. Will it be possible to change it so that it is validated in the persistense or identity, based on a userid from the claims?
This would work only if you are also the identity provider. Otherwise, you don't hold or manage the user's permission/roles. If you're also the identity provider, then yeah sure, you have access to all the data you need to authorize or forbid access based on the user id
@@amantinband that might not be entirely true. I have a project where Azure AD B2C is responsible for authentication, and then an implementation internally in the API is responsible for managing users' permissions. This separation between authentication and authorization is preferable, in my opinion. My project don't need to be the identity provider for that to work, I only need to manage the authorization part. This also makes the permission evaluation perform well also for larger projects where a single user potentially ends up with thousands of granular permissions on different resources (e.g. a user has "manage" permission on one resource, but only "read" on another resource, etc).
You're right, I said "if you're also the identity provider" and should have said "if you also manage the user's permissions". Thanks for the correction 🙂
Thanks for both the video and source code! 🙌 Do you happen to have any other videos / good resources more specifically on the policy implementation and how policies can be structured for scalability, simplicity and maintainability?
I do not think so. If you see the books they place it in the domain because repository operations should come from the ubiquitous language, contained by the domain. Also, putting them in your domain makes you able to use the interfaces in domain services.
Great content🙂! I'm curious, will there be a sequel to your DDD and Clean Architecture courses on DomeTrain? It feels like some key pieces are still missing, particularly on the unhappy path 1) Eventual consistency within the domain while processing the domain events goes wrong(just sending an email is not realistic, what if we need to roll back) 2.Integration events handling and transactions between microservices(MassTransit with Outbox and Saga patterns?)
I wonder why most authors expose foreign keys in entities when representing relationships. For example: Why not private readonly List _reminders = []; Instead of private readonly List _reminderIds = [];
The .NET Microservices: Architecture for Containerized .NET Applications ebook says: A DDD domain model is composed from aggregates, an aggregate can have just one entity or more, and can include value objects as well. In order to maintain seperation of aggregates and keep clear boundaries between them, it is a good practice in a DDD domain model to disallow direct navigation between aggregates and only having the foregin key (FK) field.
@@jeffreyvdb Thanks for your answer. Another thing that called my attention in several examples, is the use of the foreign key, and also the entity, to represent a relationship. For example: public class TodoItem { public int Id { get; set; } public int ListId { get; set; } public TodoList List { get; set; } = null!; } I wouldn't add ListId property. It sounds more like a database concept to me. What is the advantage of adding the foreign key in this case?
Having infrastructure is debatable. I love to have each domain completely independent from each other. Having contracts only to interact with it. Inside domain in a namespace is infrastructure code. Likewise each domain does not rely on common table or infra. Goes into this modular monolith. Even endpoints could be out of API in a separate project to leave api just a dumb shell and bootstrap
I think sometimes that .Api and .Application levels must be named in some other manner. Because i had some cases when it was useful to code several applications sharing the same domain. For example, CRUD service (working with database as signgle replica), some business service (working with message brokers as several replicas) and may be can exist some desktop application like WPF- or Avalonia- based application. The exact structure of services can be re-organized after changing of actual production workload, but it`s definetely cannot be the reason to change domain - just re-structure applications that use this domain. So i think that top level project can be named not only as .Api, but also as .App. It would be very convenient. But in this case, it would be similarity between .App and .Application. So the idea is not completely good. I would hear some sample of such cases, because i think that Clean Arch is mos powerful exactly in sutuations with multiple Api or applications with shared domain, in this case some architecture levels becomes more justified.
Hello sir, I was a member on patreon but due to some financial issue it will not be possible to continue membership and a also want to study Deep Dive: Clean Architecture in .NET course but i'm not able to pay you as course fee $89.99 could you provide me low fee for that course.
Good to see you back man ❤
I actually love how the Authentication is done Here. I have a quite similar Solution Template where much more things are Automated, especially the repository with caching, but authentication is a Part i am missing currently.
FYI, I don’t need a reminder to tell you I love you 🤣
Oops I put your name? wrong wife
What a tribute
😅😅wow@@amantinband
Hello Ami, it's great to have you back man. Just to be sure and for the sake of other viewers who will be watching this, the step involving the conversion of incoming requests into commands or queries does not necessarily imply the usage of the CQRS architectural pattern. Does it?
Thanks, one of the most clear templates on internet!
so many clean architecture templates out there, i will take a look
nice video, I have a question, if I have some azure durable functions with service bus triggers that handle business processes, where would you locate them?
Thanks,
What do you think about using the domain models directly as the database entities or creating a persistence model for the database and then mapping them back and forth between domain to db entity and vice versa?
I saw it as a challenge in real-world apps when having a complicated domain entity to be used directly as a database entity, at the same time, the mapping between domain models/persistence models also a challenge sometimes
Configuring the mapping between domain objects and the database is very flexible with EF Core. Personally, I dislike creating and maintaining another set set of persistence models.
Great template! Very close to Jason Taylor's with a few tweaks. One thing I'm surprised about the sample code is the Amichai allows Entities to be created in an invalid state. I can create a Reminder with a NULL text field, or a user with NULL first, last, and email. Obviously not an issue with the template, just an observation of the sample code.
Yep our templates have many similarities and I reused a few of his great ideas. Regarding entity construction, you can definitely re-validate the validations done early up stream if you think it adds value to your project/team.
That's great video Amichai 🙂
Hey Amichai, I am having a lot of trouble trying to deploy this demo on K8s. Can you give a couple of tips? I am just trying to create an image based on your docker file but it is not working. I want to show my boss that this should be how to work properly. But still, no luck deploying
Help. My authorization not working. Did anyone has same issue ?I implementing IAuthorizable on one of the request and added Authorize attribute. I did register openbehaviour Authorization. What am I missing. IAuthorizable should be added somewhere ?
Logic in the domain ?
I though that the logic was suposed to be in the application layer, can you please give me a insight brother?
Thank you and sorry for the poor english. Im trying to improve it.
Nice one Amichai. I review such templates. Heads up: I noticed the short name clashes with Steve "Ardalis" Smith's template (clean-arch), so they don't work on the same machine in parallel unless you specify the full name.
I'm especially interested in how you handle repository querying/specifications; Ardalis' Specifications library being on my lookout.
I'll give a proper review after trying this out in use cases
Thanks Amichai, wish to make a playlist for real-time in .Net
In your clean architecture tutorial playlist you used Aggregator pattern. Here you dont have that. any specific reason for that ?
too sad that such monolithic architectures era is ending. I wonder how we can apply this to a microservice approach.
Can you provide a quick comment on why you are seperating the API requests and responses in an other class lib.? It looks neat but is it the only reason?
great to see you making another video!😊
May I know how the AppDbContext works in Repository without constructor?
Good content. Thanks! Definitely some nuggets of information that I can use in my Clean Architecture journey.
Cool template, mine's pretty close, but I learned some new stuff to add to mine from yours! Thank you
Welcome back!!
We came up with an almost identical project arrangement in a new solution recently. I remember a lot of discussion around having separate Domain and Application project layers. We ended up having a single project for domain and application because it didn’t seem like having two added much value. Obviously every project has different needs, but when do you think it makes sense to truly separate the Domain from Application?
I think the commands and everything else should only be on the application layer since the domain does not need to be concerned about that. The domain should be only concerned about business rules.
Both are good approaches, and there are multiple templates that have a single project (usually named "core") for both the Application and Domain logic.
Personally, I much prefer the separation. As Alisson said, the domain should contain the business logic and rules, while the application layer is just the orchestrator of the various domain objects and services. The project separation forces this separation of concerns and limits the domain layer from having access to all the various application layer interfaces
Makes sense. For our solution, the “domain” is largely dumb models for state and business logic Action (or “service”) classes. But if CQRS or DDD come into the picture, I can see some value in having separate projects
אחלה ווידאו :) , אני ממליץ לך להשתמש ב minimal api, זה נכנס חזק עכשיו
Nice video. Thanks. May I ask, how do you make these explanations, arrows and boxes in live video?
Thanks. I use Presentify (macOS only)
Very cool and organized structure 👍, I will check it in my next projects.
Could you please tell me what this tool that you used to highlight and write on screen, I like it.
Presentify?
yep, presentify
Thanks for sharing. This is great!
Great video 🎉 you are using wich tool to draw arrow and box on your screen ?
Thanks. I use Presentify (available only on macOS)
I noticed that the logic of the commands is in the domain class User (e.g., DismissReminder). I'm a little confused now, isn't the application's layer job to handle the logic? Why do we have that in the domain layer instead?
No. Taking the method you gave as an example:
public ErrorOr DismissReminder(Guid reminderId)
{
if (Subscription == Subscription.Canceled)
{
return Error.NotFound(description: "Subscription not found");
}
if (!_reminderIds.Contains(reminderId))
{
return Error.NotFound(description: "Reminder not found");
}
if (_dismissedReminderIds.Contains(reminderId))
{
return Error.Conflict(description: "Reminder already dismissed");
}
_dismissedReminderIds.Add(reminderId);
_domainEvents.Add(new ReminderDismissedEvent(reminderId));
return Result.Success;
}
The application layer's responsibility is to orchestrate the domain objects (i.e. fetch the user domain object from the database and invoking the DismissReminder method).
The actual decision if the reminder can be dismissed, is the responsibility of the domain. All the various actions that change the underlying state of domain objects is considered domain logic and is encapsulated inside the domain objects or services.
@@amantinband Thanks, that cleared some of the confusion regarding the role of the application layer. I still have some concerns that putting the logic inside the domain layer might cause some issues (for instance, what if we needed to access a service using dependency injection?)
How do you Return a qualified not authenticated http response for your Controllers when using mediatr middleware to check
Authentication is done using the built in middleware. Authorization is done via the mediatr middleware, and there is a mapping between the ErrorOr.Unauthorized error type to the Forbidden status code in the base controller
Where would you locate hubs from signalr?
src/CleanArchitecture.Api/Hubs/YourHub.cs
Just one question, I saw that the permission goes in the claims, when the project scales this could be a problem because it could end up with too many permissions, slowing down all requests because the token is very large. Will it be possible to change it so that it is validated in the persistense or identity, based on a userid from the claims?
This would work only if you are also the identity provider. Otherwise, you don't hold or manage the user's permission/roles. If you're also the identity provider, then yeah sure, you have access to all the data you need to authorize or forbid access based on the user id
@@amantinband that might not be entirely true. I have a project where Azure AD B2C is responsible for authentication, and then an implementation internally in the API is responsible for managing users' permissions. This separation between authentication and authorization is preferable, in my opinion. My project don't need to be the identity provider for that to work, I only need to manage the authorization part.
This also makes the permission evaluation perform well also for larger projects where a single user potentially ends up with thousands of granular permissions on different resources (e.g. a user has "manage" permission on one resource, but only "read" on another resource, etc).
You're right, I said "if you're also the identity provider" and should have said "if you also manage the user's permissions". Thanks for the correction 🙂
You are the best!
Does anyone know how Amichai draws those arrows/ boxes? Is that a program or smth?
Presentify (macos only though). If you're on windows, check out zoomit
Thanks for both the video and source code! 🙌
Do you happen to have any other videos / good resources more specifically on the policy implementation and how policies can be structured for scalability, simplicity and maintainability?
Thanks. Didn't create one yet. I have it planned for the future but it's not prioritizing since I think it's more niche than others planned
Thank you!
Why do you place your repository interfaces in Application instead of Domain layer?
B/c that's the correct think to do
I do not think so. If you see the books they place it in the domain because repository operations should come from the ubiquitous language, contained by the domain. Also, putting them in your domain makes you able to use the interfaces in domain services.
Great content🙂! I'm curious, will there be a sequel to your DDD and Clean Architecture courses on DomeTrain? It feels like some key pieces are still missing, particularly on the unhappy path
1) Eventual consistency within the domain while processing the domain events goes wrong(just sending an email is not realistic, what if we need to roll back) 2.Integration events handling and transactions between microservices(MassTransit with Outbox and Saga patterns?)
Thanks Omid! Yep, there will hopefully be two follow up courses on the DDD course.
would love a simple blazor frontend
discount code invalid.
Great courses in dometrain 🔥
I wonder why most authors expose foreign keys in entities when representing relationships.
For example:
Why not
private readonly List _reminders = [];
Instead of
private readonly List _reminderIds = [];
The .NET Microservices: Architecture for Containerized .NET Applications ebook says:
A DDD domain model is composed from aggregates, an aggregate can have just one entity or more, and can include value objects as well.
In order to maintain seperation of aggregates and keep clear boundaries between them, it is a good practice in a DDD domain model to disallow direct navigation between aggregates and only having the foregin key (FK) field.
@@jeffreyvdb Thanks for your answer.
Another thing that called my attention in several examples, is the use of the foreign key, and also the entity, to represent a relationship.
For example:
public class TodoItem
{
public int Id { get; set; }
public int ListId { get; set; }
public TodoList List { get; set; } = null!;
}
I wouldn't add ListId property. It sounds more like a database concept to me.
What is the advantage of adding the foreign key in this case?
Clean Architecture was nice in its time when we were working on larger monolithic OOP applications. Not so much value today.
it definitely depends both on the project and (more importantly IMO) the team
Having infrastructure is debatable. I love to have each domain completely independent from each other. Having contracts only to interact with it. Inside domain in a namespace is infrastructure code. Likewise each domain does not rely on common table or infra. Goes into this modular monolith. Even endpoints could be out of API in a separate project to leave api just a dumb shell and bootstrap
Mwahh prefer DDD, this seems so hackish
I think sometimes that .Api and .Application levels must be named in some other manner.
Because i had some cases when it was useful to code several applications sharing the same domain.
For example, CRUD service (working with database as signgle replica), some business service (working with message brokers as several replicas) and may be can exist some desktop application like WPF- or Avalonia- based application.
The exact structure of services can be re-organized after changing of actual production workload, but it`s definetely cannot be the reason to change domain - just re-structure applications that use this domain.
So i think that top level project can be named not only as .Api, but also as .App. It would be very convenient. But in this case, it would be similarity between .App and .Application. So the idea is not completely good. I would hear some sample of such cases, because i think that Clean Arch is mos powerful exactly in sutuations with multiple Api or applications with shared domain, in this case some architecture levels becomes more justified.
I agree. It's project dependent
Hello sir, I was a member on patreon but due to some financial issue it will not be possible to continue membership and a also want to study Deep Dive: Clean Architecture in .NET course but i'm not able to pay you as course fee $89.99 could you provide me low fee for that course.
"ultimate"? 😶