Timeline for Avoid updating multiple Aggregates in Library Application
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 29 at 23:42 | comment | added | Flater | @securita: That's not what a dependency is. The ability for me to e.g. mass-archive a bunch of data does not somehow invalidate the independent nature of the aggregates. The persistence mechanic is unrelated to my domain logic. You are correct that the domain logic shouldn't use checks where one aggregate's update hinges on whether another aggregate's update worked; but this does not apply to the persistence mechanism used to store said aggregates. | |
| Apr 29 at 19:27 | comment | added | nicholaswmin | Hi, I wrote that question a long time ago. Forget about transactions in a distributed system. You want queues. This is the direction we went after I posted that question and it has served us magnificently. I have the gut feeling, the OP was in a similar state of shock as I was back then, learning that microservice architecture just don't like transactions. | |
| Mar 29 at 13:00 | history | edited | Rik D | CC BY-SA 4.0 |
added 320 characters in body
|
| Mar 28 at 22:37 | comment | added | securita | Then the aggregates would depend on each other. I dont think that is how aggregates should be designed. | |
| Mar 28 at 6:46 | history | answered | Rik D | CC BY-SA 4.0 |