Timeline for OO Design - Encapsulation question
Current License: CC BY-SA 4.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 10, 2019 at 15:15 | comment | added | Subhash | Because you cannot load all reward objects along with shop object for performance reasons, but want to enforce constraints, you would go with eventual consistency. You would add a reward object outside the shop class, but publish a domain event. Then a subscriber listening to the domain event will ensure the business constraint is satisfied in the Shop object. If the invariant is not satisfied, then you would do a compensating transaction or raise an exception to be handled manually by an administrator. That's the price to pay in complexity when you separate them into two aggregates. | |
| Sep 10, 2019 at 15:01 | comment | added | charliebrownie |
I see! So what do you think would be the way to go if rules change and the possibility of ending up having a big number of rewards objects exists? I am wondering if breaking the shop->reward[] aggregate and managing a shop's reward list independently would make more sense in that case... what would be your point of view in this scenario you very well brought up?
|
|
| Sep 10, 2019 at 6:47 | history | answered | Subhash | CC BY-SA 4.0 |