Get related aggregates from using ES and repositories

[David Reynolds]

Hi,

If I have a domain with Manager and Employee.  Employee has a Guid ManagerId field that references the Managers Id.  If an ES repository can only get an aggregate by Id how do I go about getting a list of all the employees for a given manager?

Thanks

[Colin Yates]

My (limited) understanding is that it is fine for the domain to
reference views, so your Manager would call
view.findEmployeesFor(managerId).

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[David Reynolds]

Should have said that I was thinking about this in terms of a command.  I was under the impression that commands shouldn't use the read model.  I also thought any business decisions should be done using the aggregates not the read model as it's eventually consistent.  So, if i wanted to make a business decision based on a manager and their employees how would I get the list of employees based on a "foreign key"?

[Colin Yates]

either have a dedicated read model just to answer that query or use an
existing one from the query side. Obviously you will need to consider
eventual consistency as well.

Alternatively, just answer the question at run-time by parsing all the
relevant events (EmployeeAdded for example)- not sure about
performance implications though

On 20 April 2015 at 12:02, David Reynolds <daverey...@gmail.com> wrote:
> Should have said that I was thinking about this in terms of a command. I

> was under the impression that commands should use the read model. I also
> thought any business decisions should be done using the aggregates. So, if

> i wanted to make a business decision based on a manager and their employees
> how would I get the list of employees based on a "foreign key"?
>
> On Monday, 20 April 2015 11:59:14 UTC+1, Colin Yates wrote:
>>

[David Ackerman]

I don't think there is anything stopping you from making business decisions across aggregates, it's just that the logic can't assume they are transactional or consistent.  Most of the time, this is okay for the business - a common trick in this world is to think about how the business would solve the problem if they were manually writing information down on pieces of paper and mailing it to each other - how would they handle situations where two people do incompatible things due to their not having a perfectly up-to-date view of the world?

For instance, say you had a "rule" that a manager can't have more than 10 employees report to them.  You might first think you need to transactionally enforce this constraint between a manager and all the employees that report to them. However, think about a real-world scenario... what if someone actually had 11 reports? Should the system just ignore that possibility? Maybe there should be a warning message on the profile of the manager if they go past 10 reports that they need to transition one away - but that takes time and the system should handle that.

Maybe it's not a super-realistic example - but hopefully you get the idea - usually the real world has some of this type of complexity anyway and by modeling it, you might actually make the application more useful than if these constraints were enforced at a technical level.

That said, allowing things to be eventually consistent does have a cost of complexity.  Sometimes it just makes sense to put the relevant information into one aggregate, or even just ignore the possibility of inconsistency and correct the problem later as a one-off.  If you have a specific scenario you're thinking of modeling, we might be able to give more ideas about how you could either reorganize aggregates or handle the eventual consistency issue.

[@yreynhout]

What function does the Manager want to invoke on his Employees? Fire(); or Raise(); or DoAnnualReview(); or InviteToCompanyDinner();

[David Reynolds]

Something like that yes. It was just meant to be an example to demonstrate the problem.

[@yreynhout]

Then show me the atomicity problem ...

[Ramin]

Aggregates protect invariants. Business decisions are based on the read model all the time in the real world. Once a decision is made based on the read model, the command is sent to an aggregate which then makes sure its own invariants are maintained. Or to a domain service which invokes > 1 aggregate, if that is absolutely necessary. After that you can have compensating actions in case the read model was not accurate or not up to date. Lets assume you invite your employees to a company dinner based on a list of employees you have. An hour later you realize that the new employee was missing from that list. The compensating action would be to now send an invitation to that employee. The compensating action can be (semi) automated or not, depending on the requirements.

[r.ru...@devarium.fr]

Here is a very interesting video on the subject of making decisions based on the eventually consistant read model: https://skillsmatter.com/skillscasts/1250-udi-dahan-command-query-responsibility-segregation

It also states that a good command should always result in your front saying "Thank's, we'll let you know if something went wrong".

It very well adresses the concept of the read model,

Hope this link makes sense.