Timeline for Where to check for invariants between two aggregate roots?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 7, 2022 at 18:44 | comment | added | Flater | @kibe Your agent sounds more like an authorization role than an entity for this particular topic. If this is its only purpose, it should be implemented as an authorization check in the service layer. | |
| Mar 7, 2022 at 15:30 | comment | added | kibe |
Last question, and I'm sorry for asking too many questions; what would be the role of Agent here? Just to follow the ubiquitous language, should the Agent be the one responsible for telling the Company to add a phone number to a department? Should the Agent itself check whether the phone number is available? It just seems weird that the company would self-check it, it seems like a human's job. Thanks.
|
|
| Mar 7, 2022 at 15:29 | comment | added | kibe |
Oops, yeah! I get it now, sorry. It all makes sense now. And it's indeed better to Department not as an AR, but as an entity. Because otherwise, if I need to fetch all the phone numbers of a given company, I'd have to fetch the company AR, then fetch all departments AR, and then send them to a GetAllPhoneNumbersOfCompany domain service. There would be a bunch of domain services. The entities would be too anemic. You're right.
|
|
| Mar 7, 2022 at 15:02 | comment | added | Flater | @kibe Your conclusion is not what this answer suggests. The suggestion here is to store department phone numbers in departments, and any non-department phone numbers in the company. When you need a list of all of the company's phone numbers, you can combine the sources. | |
| Mar 7, 2022 at 14:21 | comment | added | kibe |
You're right. It seems like the only way is to have Company have all phone numbers and Department totally devoid of its phone number. It does seem weird because that's not how it works in real life, but it is what it is. I do, however, have to constantly query for a specific department given a phone number. Perhaps I'll build a view model (PhoneNumber -> Department) which is eventually consistent but hopefully fast enough. Would you do the same if you were tasked with that requirement? Thanks.
|
|
| Mar 7, 2022 at 14:06 | history | edited | Flater | CC BY-SA 4.0 |
added 90 characters in body
|
| Mar 7, 2022 at 14:04 | comment | added | Flater |
@kibe: You're trading one job of having to manage the data consistency for another; because then you'd have to make sure the departmentId of the phone number is part of the companyId of the phone number. Having a third aggregate root here would be complete overkill here. When every object is its own aggregate root; you're basically not working with aggregates at that point.
|
|
| Mar 7, 2022 at 13:43 | comment | added | kibe |
Perhaps PhoneNumber could be an entity? It would contain a companyId and departmentId. It would solve the duplication issue; a PhoneNumber can only be created with a companyId at first, and be assigned a departmentId later on. Might be too overkill to have yet another entity, though.
|
|
| Mar 7, 2022 at 13:40 | comment | added | kibe |
Hi, thanks for the suggestion; indeed, there is a duplication going on, thanks for pointing that out. Are you suggesting that Company becomes the single source of truth--it having something like (Map<PhoneNumber, Department>)? If so, although it'd work, it is essential for me to be able to query a department by a phone number.
|
|
| Mar 7, 2022 at 9:30 | history | edited | Flater | CC BY-SA 4.0 |
added 281 characters in body
|
| Mar 7, 2022 at 9:25 | history | answered | Flater | CC BY-SA 4.0 |