Practical Domain-Driven Design with EF Core - Hossam Barakat - NDC London 2021

  Рет қаралды 17,736

NDC Conferences

NDC Conferences

Күн бұрын

Пікірлер: 22
@branislavpetrovic7486
@branislavpetrovic7486 3 жыл бұрын
Thanks for this great talk! Nice explanations of important aspects of strategic DDD.
@user-xu8dq5nj3e
@user-xu8dq5nj3e Жыл бұрын
I wish I had seen you before. excellent report, thank you.
@Reaper21154
@Reaper21154 2 жыл бұрын
Excellent talk! Thank you Hossam
@mohamedal-qadeery6530
@mohamedal-qadeery6530 Жыл бұрын
This is so good learned alot ! thanks for this content
@mohammadsj
@mohammadsj 9 ай бұрын
This is the best DDD presentation. Thanks you.
@sajagjain7169
@sajagjain7169 2 жыл бұрын
Thanks for the great talk.
@user-yb4jd5jv2f
@user-yb4jd5jv2f Жыл бұрын
Great! Thanks for explanation. Domain event bus via interceptor in good idea.
@HFamilyDad
@HFamilyDad 3 жыл бұрын
Very Good!
@jz5153
@jz5153 2 жыл бұрын
Pretty sure refactored code won't work, Customer.Subscriptions doesn't have any setter and is reado only so EF won't be able to populate it.
@vincentcifello4435
@vincentcifello4435 Жыл бұрын
Thanks for this great presentation! Shouldn't Product be its own Aggregate that is referenced in Subscription by ProductId instead of as a Navigation Property? I realize this demo has everything completely locked down with private setters and creation-only functionality, but Product doesn't appear to have a proper place in the Customer Aggregate Root's transactional boundary. In a realistic scenario where Product is a mutable entity, it will be retrieved by reference from Subscription even with Subscriptions as ReadOnly. It can then be mutated and will be persisted with SaveChanges(). I don't mean to be critical. I've watched this presentation several times to help consolidate my understanding.
@aaryavartsolutions5359
@aaryavartsolutions5359 2 жыл бұрын
Where is the UI? The source code only contains Api
@jeremyhb1393
@jeremyhb1393 Жыл бұрын
Good job ! Thanks for the explanation man ❤ i have a small question. is it good approach to use domain event sourcing to validate our business rules in other word can domain event solve this scenario "An employee cannot be removed from a department if they have ongoing projects or responsibilities within the department".
@dllamaree
@dllamaree Жыл бұрын
Domain event sourcing can be an effective approach for managing complex business scenarios, but it is not specifically meant for validating business rules. Instead, it is a pattern used for capturing and storing the history of events that have occurred within a domain. For your particular scenario, you can use Domain-Driven Design (DDD) principles to model the Employee and Department entities along with their related business rules. To prevent an employee from being removed from a department when they have ongoing projects or responsibilities, you can implement a domain service or policy that enforces this business rule and ensures the department's consistency. For example, you could create an EmployeeRemovalService with a method called "remove_employee_from_department()" which checks if the given employee has any ongoing projects or responsibilities. If they do, the method should raise an exception, indicating that the employee cannot be removed. If not, the employee will be removed from the department. Here's the example code in C#: public class Project { // ... other properties and methods ... public bool IsOngoing() { return Status == "ongoing"; } } public class Responsibility { // ... other properties and methods ... public bool IsOngoing() { return Status == "ongoing"; } } public class Department { // ... other properties and methods ... public bool CanRemoveEmployee(Employee employee) { foreach (var project in employee.Projects) { if (project.IsOngoing()) { return false; } } foreach (var responsibility in employee.Responsibilities) { if (responsibility.IsOngoing()) { return false; } } return true; } } // or using LINQ public bool CanRemoveEmployee(Employee employee) { return !employee.Projects.Any(project => project.IsOngoing()) && !employee.Responsibilities.Any(responsibility => responsibility.IsOngoing()); } // public class EmployeeRemovalService { public void RemoveEmployeeFromDepartment(Department department, Employee employee) { if (department.CanRemoveEmployee(employee)) { department.RemoveEmployee(employee); // Emit a domain event, e.g., EmployeeRemovedFromDepartment } else { throw new InvalidOperationException("Cannot remove employee with ongoing projects or responsibilities"); } } } In the client code, you would use the EmployeeRemovalService to remove an employee from a department: var employeeRemovalService = new EmployeeRemovalService(); try { employeeRemovalService.RemoveEmployeeFromDepartment(department, employee); } catch (InvalidOperationException ex) { Console.WriteLine($"Error: {ex.Message}"); } This solution ensures that the business rule is enforced within the domain model while maintaining a separation of concerns and robustness of the validation logic. Domain events can still be used in conjunction with this approach, but they should be focused on capturing and reacting to changes in the system rather than validating business rules. I hope this helps!
@jeremyhb1393
@jeremyhb1393 Жыл бұрын
@@dllamaree Thank you for your reply and help ❤, it means a lot to me!
@josersleal
@josersleal Жыл бұрын
where is the code?
@tiagosantos2136
@tiagosantos2136 2 ай бұрын
White screen 😩
@xiaoguoge2752
@xiaoguoge2752 3 жыл бұрын
Better to move away from interfaces and mocking and stay with static functions.
@fieryscorpion
@fieryscorpion Жыл бұрын
I'm curious. One question: How does testing work in that scenario?
@xiaoguoge2752
@xiaoguoge2752 Жыл бұрын
@@fieryscorpion you are assuming dependency has to be added as interfaces and mocked in tests. A better approach to writing all domain services as stateless static functions and just call the function directly. Calling a stateless function is no different than calling the math operators, and nobody ever asked how to mock the +, -, *, / operators in tests. When you do want to use fake functions in tests, just take the function as a parameter and pass whatever you want to pass as input parameters.
@fieryscorpion
@fieryscorpion Жыл бұрын
@@xiaoguoge2752 That’s a great way of looking at it. Thank you! I’ll try to use it. Do you, by any chance, have an example repo that I can look at?
@xiaoguoge2752
@xiaoguoge2752 Жыл бұрын
@@fieryscorpion there are some examples on page 11 of this talk docs.google.com/presentation/d/1MdKSp5369cT2fS9HVx0wkT-xa1XAI7QtmPkiK7_L-j4/edit?usp=sharing
@smithdragon6477
@smithdragon6477 6 ай бұрын
Seems professor passed domainservice to an aggregate . Want to know is ddd recommend way to do this. Because we can use domainservice can also achieve this .very confused eg: customer.AddSubscription(product, _calculator.CalculateSubscriptionAmount(product, customer));
Jeevan Singh -- The Future of Application Security Engineers
46:59
The Application Security Podcast
Рет қаралды 2,2 М.
孩子多的烦恼?#火影忍者 #家庭 #佐助
00:31
火影忍者一家
Рет қаралды 46 МЛН
That's how money comes into our family
00:14
Mamasoboliha
Рет қаралды 7 МЛН
The child was abused by the clown#Short #Officer Rabbit #angel
00:55
兔子警官
Рет қаралды 24 МЛН
Domain-Driven Refactoring - Jimmy Bogard - NDC London 2022
1:00:03
NDC Conferences
Рет қаралды 44 М.
Practical Domain-Driven Design with EF Core - Hossam Barakat
55:13
NDC Conferences
Рет қаралды 28 М.
Чистая архитектура и Domain-Driven Design
1:55:56
ОБСЛУЖИЛИ САМЫЙ ГРЯЗНЫЙ ПК
1:00
VA-PC
Рет қаралды 864 М.
Tag her 🤭💞 #miniphone #smartphone #iphone #samsung #fyp
0:11
Pockify™
Рет қаралды 19 МЛН
YOTAPHONE 2 - СПУСТЯ 10 ЛЕТ
15:13
ЗЕ МАККЕРС
Рет қаралды 175 М.