Really great session, You certainly know your craft! Thanks for taking the time to do this, much appreciated and looks like a great product. Would also be interested on the session on micro services.
you can use double dispatch to inject the product repository to the domain method. that way you can unit test the domain model and the the business logic now live in domain model rather in handler/service at 52mins
Hi Trong, thank you for your comment. I'm not sure if I'm fully understanding exactly what you're suggesting. Would you mind elaborating? I think viewers would find it valuable. To try give some initial input in the meantime: I think it may be worth noting that the repository interfaces in this architecture are available in the Domain Layer, which means one could pass in the repository service to an operation on an Entity. In this case we would have one Aggregate mutating the state of another. This may be fine in some cases but typically isn't ideal, especially when this pattern propagates throughout the domain and can create far reaching dependencies as all repositories need to be provided for all affected aggregates at the entry point operation. A better alternative would be to create a Domain Service which would encapsulate the business logic of retrieving and mutating the other aggregate(s) in the process, and instead inject this into the operation. This would limit the dependency graph. One could also use Domain Events (as we did in the webinar) to propagate changes between aggregates (side effects) without introducing dependencies to the entry point operation - this is what the Domain Event pattern excels at. These two approaches could be combined so that all business logic remains in the domain, while we simultaneously maintain low-coupling throughout the domain.
![เปิด อาณาจักร หมื่นล้าน "สาระตั้ม" l [Nickynachat]](http://i.ytimg.com/vi/3XE0nPF4YkQ/mqdefault.jpg)
Interesting stuff! Enjoyed the theory immediately backed up by the practical!
Glad you found the session valuable!
Really great session, You certainly know your craft! Thanks for taking the time to do this, much appreciated and looks like a great product. Would also be interested on the session on micro services.
Glad you enjoyed it!
you can use double dispatch to inject the product repository to the domain method. that way you can unit test the domain model and the the business logic now live in domain model rather in handler/service at 52mins
Hi Trong, thank you for your comment. I'm not sure if I'm fully understanding exactly what you're suggesting. Would you mind elaborating? I think viewers would find it valuable.
To try give some initial input in the meantime:
I think it may be worth noting that the repository interfaces in this architecture are available in the Domain Layer, which means one could pass in the repository service to an operation on an Entity. In this case we would have one Aggregate mutating the state of another. This may be fine in some cases but typically isn't ideal, especially when this pattern propagates throughout the domain and can create far reaching dependencies as all repositories need to be provided for all affected aggregates at the entry point operation.
A better alternative would be to create a Domain Service which would encapsulate the business logic of retrieving and mutating the other aggregate(s) in the process, and instead inject this into the operation. This would limit the dependency graph. One could also use Domain Events (as we did in the webinar) to propagate changes between aggregates (side effects) without introducing dependencies to the entry point operation - this is what the Domain Event pattern excels at.
These two approaches could be combined so that all business logic remains in the domain, while we simultaneously maintain low-coupling throughout the domain.