This is from a vaguely interested outsider, I hope an expert chimes in. My understanding is that in choreographic programming, the protocol/choreography is con

This is from a vaguely interested outsider, I hope an expert chimes in. My understanding is that in choreographic programming, the protocol/choreography is considered an explicit "thing". That explicit thing is explicitly defined in one place, as opposed to the implementation being divided up across multiple places, like the client, server, etc. This is the explicit opposite of "reason[ing] about each object/microservice in isolation", at least with regards to the protocol. Since the protocol is one "thing", there is no reason for abstraction: Abstraction is for when you combine multiple "things". In the example, the client's network code may know about internals of the service's network code, but that's not a problem. This doesn't mean that the client's business logic knows about the service's business logic. It's also not a problem that the client knows that there is a separate login provider that could be communicated with. You may be thinking, "oh, if the client knows about the login provider, it might try to talk to it directly". But no, because the entire network code is generated based on the protocol specification, and the protocol specification doesn't include this. You might take the generated network code and break it by hand. I guess the response to that is, "please don't". Again, I hope someone can correct this or explain it better.