[aaronyo]

I think it's possible to get many of the benefits by decomposing your back end into logical subsystems (still running in the same process, etc.) or vertical slices from the get go, rather than starting out with some fixed number of layers that horizontally span your app. I'm building a JSON API right now this way. My take is that Dividing first by subsystems and then by layers prevents the growth of monolithic layers and lets each subsystem evolve independently. If you have contracts between the systems, you can later split them out onto separate boxes. So far, it feels reasonable. You do give up querying across all your tables. We're trialing Mongo (jury still out on that choice) which means we don't have the option to join anyway. The bet is that we'll need other data systems for reporting style queries or other data processing, but that's not the major concern of the JSON API.

I believe that breaking up the code this way makes it easier to reason about the app (isolate probs, etc.) and provides more modularity and flexibility then when your primary division is layers. Not sure why, though, you'd want to go the extra step of physical isolation from the beginning. Why? Unless, perhaps, you feel it is the only way to enforce the separation of systems.