keyvanakbary
commented
6 years ago Reminder about the use for this repository: report issues with the book. Maybe for asking questions you can reach us out through email or Twitter 👍
Being said that, from your example it looks like a Student is the Aggregate Root, at least for the Rank (or score he has). Rank looks more of a Value Object, as it doesn't have identity (two Students can have same Rank). Only Aggregate Roots should have a Repository. Unless you calculate the score in an async way, you can place the updating score logic right after you attach a new Grade to the Student. As I guess you don't want to have a new Grade without updating the Rank, a transaction should happen, and that transaction should always happen at the infrastructure level. You can wrap the entire Application Service entry point into a class that operates Application Services inside transactional blocks as we show in the book. You'll have to remember that you need to wrap your top-level application service with the transactional block (that flushes the commit at the end of the Application Service) every time you use that domain service, which I agree, kinda sucks a bit 😂
I hope it helps a bit 🙂
It is hard to come with a short/valid example, but do I always have an application service? If not where would I handle the transaction aspect if I am not supposed to add this to the domain (and therefore not to add to a domain service). Also do I call a domain service from an application service?
Example domain: I have the concept of a Student (with his grades), and a Rank (with the average of all grades). If I am asked to calculate the rank and persist it I would create a domain service as it does not belong to the Student nor the Rank that would likely call a RankRepository implementation to add a Rank. In this case where is the (flush) commit happening?