Thanks for this great talk! Nice explanations of important aspects of strategic DDD.
@mohammadsj11 ай бұрын
This is the best DDD presentation. Thanks you.
@user-xu8dq5nj3e Жыл бұрын
I wish I had seen you before. excellent report, thank you.
@mohamedal-qadeery6530 Жыл бұрын
This is so good learned alot ! thanks for this content
@user-yb4jd5jv2f2 жыл бұрын
Great! Thanks for explanation. Domain event bus via interceptor in good idea.
@Reaper211542 жыл бұрын
Excellent talk! Thank you Hossam
@sajagjain71692 жыл бұрын
Thanks for the great talk.
@jz51533 жыл бұрын
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 Жыл бұрын
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.
@HFamilyDad3 жыл бұрын
Very Good!
@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 Жыл бұрын
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 Жыл бұрын
@@dllamaree Thank you for your reply and help ❤, it means a lot to me!
@josersleal Жыл бұрын
where is the code?
@aaryavartsolutions53592 жыл бұрын
Where is the UI? The source code only contains Api
@tiagosantos21364 ай бұрын
White screen 😩
@xiaoguoge27523 жыл бұрын
Better to move away from interfaces and mocking and stay with static functions.
@fieryscorpion2 жыл бұрын
I'm curious. One question: How does testing work in that scenario?
@xiaoguoge27522 жыл бұрын
@@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.
@fieryscorpion2 жыл бұрын
@@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?
@xiaoguoge27522 жыл бұрын
@@fieryscorpion there are some examples on page 11 of this talk docs.google.com/presentation/d/1MdKSp5369cT2fS9HVx0wkT-xa1XAI7QtmPkiK7_L-j4/edit?usp=sharing
@smithdragon64778 ай бұрын
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));