to handle it without every service having a database connection to every other service's datastore you end up with something like a conversion step from Magic M

to handle it without every service having a database connection to every other service's datastore you end up with something like a conversion step from Magic Model Object to a PORO, and that sucks wind. I actually prefer the distinction: serialized domain objects do not have access to the full richness of the ORM API, so having a separate class representing the specific behavior of an API-wrapper makes a lot more sense to me. Something like ActiveModel::Serializers wraps up a lot of the boilerplate while also letting you retrieve nested object graphs in a single request: https://github.com/rails-api/active_model_serializers https://github.com/rails-api/active_model_serializers That said at Square we generally use protobuf-based RPC for our service-to-service requests, because we have a polyglot SOA so it's important for our services to produce and consume protos to support more languages than just Ruby.