A couple more that don't seem to be represented there. No mention of cause and effect, or the order in which different nodes perceive things happening? Anyway here's three which I think might be more relevant to designing and building software:

* Your system is not a distributed system

Multiple users connect, disconnect, and use your system at the same time, some of the code is running on your servers, some of it's in your partners' servers, some of it's in your storage layer, and some of it's running on your users' computers

* Your DB's ACID transactions are sufficient for distributed thinking

An ACID transaction lets you addUser() to your storage, either succeeding completely or failing completely, with no observable intermediate state. It does not let both your frontend and your storage layer addUser(), same with both your storage and your partner's storage.

* Your DB's transactions are ACID

Your DB vendors cannot build databases that are acceptably fast while running ACID. Therefore isolation is relaxed and transactions can commit through each other. Even if the DB itself was ACID, your ORM and/or programming style is likely breaking ACID independently of the DB configuration.