And scaling isn't performance, but thats a separate rant.

The complexity of software dosen't increase linearly with its size. If its very well written then you might got close but at some point everything will end up talking to everything else, then your screwed. Code can be split up into libraries and managed carefully but its still far to easy to reach around interfaces and do something bad. At its worst everything ends up talking directly to the database.

Slicing off a lump of functionality and sticking it into a service, especially if its a restful one has a knack of making you have a think about what you are trying to achieve. You can start thinking about giving the service its own independent storage. Maybe using an alternative and more appropriate technology. The dependencies and backwards compatibility are still a pain, but they were there anyway just hidden by other pain.

Imagine a system composed of 10 dice with 6 sides, how many possible combinations? A lot, I'd work it out but I can't be bothered its that big. Take that same system and slice it into 10 subsystems each of which can be in 6 very well understood states.

I know which one I'd rather test.

This will only work if they are totally different systems, the only interaction between them can be through the tested interfaces.

Why isn't it for performance and scaling, well you just picked up a load of network chatter that you are going to have to deal with. Most likely with some caching, which can be fun. But I think that its a worthwhile compromise just to separate some concerns.

I'm thinking that Clay is going to be very useful for view models and testing. The lack of intellisense will mean that I actually have to remember what the hell I've called things, but maybe that will result in better names. And there is a NuGet package as well, how nice.