Timeline for DDD - Handling temporary inconsistency when handling domain events
Current License: CC BY-SA 4.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 21, 2018 at 9:19 | vote | accept | Stefan Rendevski | ||
| Nov 20, 2018 at 19:52 | answer | added | user3347715 | timeline score: 1 | |
| Nov 20, 2018 at 19:46 | comment | added | Robert Harvey | I conclude that you don't need the scalability that microservices and eventual consistency provides. | |
| Nov 20, 2018 at 19:37 | comment | added | Stefan Rendevski | No, that kind of traffic is not expected from this app. | |
| Nov 20, 2018 at 17:51 | comment | added | Robert Harvey | I agree. Is this particular app expected to be high-traffic? (and by high-traffic, I mean a lot of traffic, on the order of Twitter or Facebook, or even Stack Overflow.) Note that Stack Overflow is a monolith. It doesn't use microservices or eventual consistency. | |
| Nov 20, 2018 at 17:50 | comment | added | Stefan Rendevski | Well immediate consistency for high traffic apps has the potential for multiple failed concurrent requests. Another "issue" is that if i want immediate consistency, i will need to have both aggregates in the same database, or rather on the same host. | |
| Nov 20, 2018 at 16:40 | comment | added | Robert Harvey | What downsides of immediate consistency are you familiar with? When you stated that "DDD advocates eventual consistency," the first thing I thought of was microservices. Microservices are the latest fad but, like the NoSQL wave before it, it comes with tradeoffs. If you're building a monolith; it's a non-issue; everything is immediately consistent. Microservices are supposed to work independently, which is why they are considered "eventually-consistent," and why hooking them up to a common database is considered a "bad practice." (scare quotes are intentional here). | |
| Nov 20, 2018 at 16:15 | comment | added | Stefan Rendevski | @RobertHarvey Well in my particular case, I cannot model the Auction in such a way, because the project I am working on does not want the real-life version of an Auction, for various reasons, meaning a user must be able to pay for every bid that he places. I do agree with you that, in the end, business rules at hand will have the final say in the design, and that software maxims serve more as a guideline than a law. I was interested to see how other people solved this problem, and if maybe immediate consistency has some downsides that I am unfamiliar with. | |
| Nov 20, 2018 at 16:08 | comment | added | Robert Harvey | Here's my point. Regardless of what Eric Evans, Martin Fowler or Vaughn Vernon says, ultimately the behavior of the system is going to be governed by the business rules at hand, not necessarily by some notion of "eventual consistency" or any other software maxims. Vaughn Vernon doesn't have to deal with auction dead-beats; the auction house does. Your job is to arrange your aggregates in such a way that you minimize immediate consistency across aggregates if you can, while still adhering to the auction house's business rules. | |
| Nov 20, 2018 at 16:04 | comment | added | Robert Harvey | Why are you worried about that? If the highest bidder cannot pay, the item goes to the next bidder, just as you said. | |
| Nov 20, 2018 at 16:02 | comment | added | Stefan Rendevski | @RobertHarvey I don't necessarily need to interrogate the account aggregate during the creation of the bid. My bigger concern was "submitting" a bid before it is paid, and having other potential bidders see this bid as valid for a time being. | |
| Nov 20, 2018 at 15:56 | comment | added | Robert Harvey | OK, so now you have a model for how it might work in your aggregates. You can do that, or you can bend the DDD rules a little bit and spend a few hundred milliseconds interrogating the account aggregate to see if the funds are available. | |
| Nov 20, 2018 at 15:54 | comment | added | Stefan Rendevski | @RobertHarvey I imagine that a real-life auction would not care about the state of a user's Account, since, at the end of the auction, if the winner cannot pay, the item would go to the next highest bidder, because in a real-life auction, a user does not "pay" for every intermediate bid he places | |
| Nov 20, 2018 at 15:53 | comment | added | Stefan Rendevski | @RobertHarvey I think that creating a bid in an Auction object needs to create an Entry in UserBalance/Account. This doesn't necessarily needs to be done in the same transaction, although I am wondering what the consequences of it might be | |
| Nov 20, 2018 at 15:52 | comment | added | Robert Harvey | How would your dilemma be solved in real-life? If an auction house accepted a bid, but later found out that the bidder had insufficient funds, how would that be worked out? | |
| Nov 20, 2018 at 15:48 | comment | added | Stefan Rendevski | @RobertHarvey In order to avoid unnecessary complexity, I omitted parts of the domain. UserBalance can contain multiple Entries, or be composed of events regarding paying/receiving funds if going with an EventSourced solution, therefore I classified it as an aggregate. Whether you call it Account or UserBalance is a matter of semantics, and i admit naming it account would have been more suitable in this case | |
| Nov 20, 2018 at 15:45 | comment | added | Robert Harvey | OK, fair enough. So now you need to craft your aggregates in such a way that aggregates can pass messages between each other without relying on inter-aggregate transactions. That ought to be solvable by working out the inter-dependencies of your aggregates and adjusting your aggregate boundaries accordingly. | |
| Nov 20, 2018 at 15:44 | comment | added | Stefan Rendevski |
@RobertHarvey Yes, I believe the following: Any rule that spans AGGREGATES will not be expected to be up-to-date at all times. Through event processing, batch processing, or other update mechanisms, other dependencies can be resolved within some specific time. [Evans, p. 128] See also this post
|
|
| Nov 20, 2018 at 15:44 | comment | added | Robert Harvey |
users might be able to see an invalid bid as the highest bid for an auction. -- Aren't bids essentially "not valid" until they are accepted?
|
|
| Nov 20, 2018 at 15:42 | comment | added | Robert Harvey |
I envisioned the following aggregates: Auction composed of Bids, User and UserBalance. -- None of those things are aggregates, except possibly Auctions. A User is an entity. A User Balance is a property of an account.
|
|
| Nov 20, 2018 at 15:40 | comment | added | Robert Harvey | Do you have a citation for the claim that "DDD advocates eventual consistency?" | |
| Nov 20, 2018 at 15:22 | history | asked | Stefan Rendevski | CC BY-SA 4.0 |