There are two types of MMO games. There are real-time games, along the lines of Eve and World of Warcraft, then there is everything else. Farmville, Mafiawars, etc. They both dictate totally different backend architectures.
For games like Farmville, your standard line-of-business type architecture will really excel, because the way users interact with the data is very similar and the data can easily be stored in a traditional Relational Database System.
Games that require real-time interaction between hundreds or thousands of players simply cannot be shoehorned into the line-of-business architecture. As @Patrick points out, many of the supporting elements of the game such as logging, authorization and authentication can be handled in a similar fashion to line-of-business applications. The tricky part, is handling "the world." This is where there really is no "right way" it all depends on how many players you expect to have, and what type of resources (programming and hardware) you are willing to throw at it.
I would argue, that you can start with a typical dedicated server setup for an FPS, and optimize from there where you start to see issues. Probably the first thing to implement is a way to have multiple of these "servers" talking to each other. Obviously you'll want to run this on a beefy physical box with plenty of bandwidth. IMO, the reason that many FPS games keep server size small, is because they know people are going to run it on some old P4 they have lying around and they'll do it on a crappy DLS connection, not because the server software cannot keep track of hundreds of players. Though I'd bet that typical "level size" is also a reason to keep the max players lower on FPS games.
The reality is that you will not have the same amount of players that World of Warcraft or Eve have overnight, and if you ever do approach those numbers where your architecture startes to show its weaknesses, I always say, that is a great problem to have because it means you're raking in the cash.
