Repository navigation
WIP: Part 1 recap - #230
Conversation
|
It has the Brandon seal of approval! |
| * Dealing with eventual consistency between aggregates can be complex. | ||
| |=== | ||
|
|
||
| Part one Recap |
There was a problem hiding this comment.
options, neither of which i'm particularly wedded to:
- keep this at end of chapter 7
- give it its own chapter
- put it in the part 2 intro
i don't have strong enough feelings to make a change, but just in case one of these sparks interest...
seddonym
left a comment
There was a problem hiding this comment.
Great changes. I've added a few thoughts but nothing major.
BTW @bobthemighty's comments on this PR would be great in the book when talking about aggregate design.
| but the failures might be more recoverable. So, as usual, the right solution | ||
| will depend on circumstances. | ||
| Again, in our simple case, it's not obvious which to prefer. In a more complex | ||
| scenario, `SELECT FOR UPDATE` might lead to more deadlocks, while `REPEATABLE |
There was a problem hiding this comment.
It feels like you're comparing apples and oranges here. Maybe pessimistic vs optimistic locking is a better comparison. (You can use SELECT FOR UPDATE to implement optimistic locking too - if you can't acquire the lock, you give up and retry later.)
| .A component diagram for our app at the end of Part One | ||
| image::images/apwp_p101.png[] | ||
|
|
||
| Well, here we are, at the end of part one. What have we achieved? We've seen how |
There was a problem hiding this comment.
I initially read this as, 'Well, where are we now in comparison to this diagram?' Maybe need to be more explicit, "Our application is now shaped like this..." or something.
| image::images/apwp_p101.png[] | ||
|
|
||
| Well, here we are, at the end of part one. What have we achieved? We've seen how | ||
| to start building a domain model that's exercised by a set of high-level unit |
There was a problem hiding this comment.
Maybe 'start building' should be replaced with 'build'?
| Well, here we are, at the end of part one. What have we achieved? We've seen how | ||
| to start building a domain model that's exercised by a set of high-level unit | ||
| tests. Our tests describe the behaviour of our system - the rules that we agreed | ||
| with our business stakeholders - in human readable prose. When our business |
There was a problem hiding this comment.
I don't think tests are written in prose!
|
|
||
| Well, here we are, at the end of part one. What have we achieved? We've seen how | ||
| to start building a domain model that's exercised by a set of high-level unit | ||
| tests. Our tests describe the behaviour of our system - the rules that we agreed |
There was a problem hiding this comment.
I have always like the phrase 'living documentation' to refer to tests.
| one we've shown, you can specify the behavior you want, and see how | ||
| it changes. You can also use the test as a basis for performing | ||
| some performance experiments. | ||
| We don't really have time to discuss all the tradeoffs between `REPEATABLE READ` |
There was a problem hiding this comment.
To clarify - I'm not sure it's right to be comparing an isolation level with a SQL command...that doesn't make sense to me.
There was a problem hiding this comment.
If you add an example of another DB's OCC mechanism (e.g., Elasticsearch), it may help clarify the point and make a clean segue between this section and the next.
I think this should satisfy @brandon-rhodes ?
Part 1 just finished unceremoniously, and we should call back to what we're trying to achieve, and psych ourselves up for how part 2 will build upon it.
I think we do want to include a paragraph on performance to the effect that: