Asynchronous messages as OOP

Originally I wanted to write about cargo cult programming, but I read Michael Feathers latest post and the idea was too good to let it pass by.

Since I’m currently struggling with creating a component system, which should serve as the base for a somewhat large domain model, I’m playing with thoughts about being able to see each component as its own small server, which can be located on some arbitrary system. This leads to a distributed system (like Amoeba as operating system), with all its advantages and drawbacks. My biggest problem so far is the communication between the components:

• either I have RPC styled services, which results in a SOA-styled architecture (which would be really awful
• or I have real messaging between objects, and must deal with all the problem which can result from a missing answer to a message

Michael solves this with removing the need for answers to messages - messages just generate more messages, and somewhere in the end the right things happens. Surely this is the essence of OOP - Alan Kay not only said the OOP for him is just passing messages between objects, he also said that on the Internet (as the prime model for a distributed system) each object should have its own IP (or at least its own URL)

But since my domain model system needs to react to requests from users (it should serve as the base for large web applications), for now I need some kind of answers to my messages. But for that, I can always use blocking and wait for the messages to flow back to the original requester

I will need to think more about that - the advantages of this model are way too large to miss them, and I hopefully can deal with all the consequences.