Well, your ideas are very vague... so can't really say it's great or not.
I can tell you how I splitted the functionality of my server. I have separate projects, they can be plugged together to run in 1 process, or scaled out to several machines:
DataModel - Contains all the data classes of entites (accounts, characters etc.) and configuration stuff
Persistence - Repository-Interfaces and some base classes to load/save data
Persistence.PostgreSQL - Implementation of the Repository-Interfaces using the PostgreSQL database
Network - some classes to create connections, sending and receiving data, including encryption
ChatServer - it manages just the chats over the MUssenger
ConnectServer - like the original, delivers the server list etc. However it has no explicit server list to configurate, game servers are registering themself with their public ip/port to it
FriendServer - manages the friend list, which means retrieving friend list, adding&removing friends, creation of chat rooms (calling the chat server), forwarding letters to the right game server, etc.
GameLogic - all the logic of the game (NO direct network or database access here yet, it calls interfaces). Each player got a "View"-Interface object, which can be implemented how you like, e.g. sending data to a client. So later it can be reused even for offline/coop-games, i just have to implement this interface to draw on the screen accordingly.
GameServer - includes the socket listener for the game server, the logic to read and send packets. After reading the values from the packets, player actions of the game logic are getting called. Implements the View-Interface by sending data packets to the connected client.
So if you want to support several client versions, you just have to implement separate views and packet reading classes for them.
LoginServer - manages the logged in accounts, so that they can only log in once
GuildServer - manages all the guild stuff, e.g. forwards guild changes to the affected game servers and their players
Startup - Plugs all the stuff together. For example, if I want a server with several sub servers (very simplified description) in one process:
I create one of each ConnectServer, LoginServer, GuildServer, ChatServer, FriendServer object. Then I create all the needed GameServer objects, each will get the dependent objects by its constructor, e.g.
Code:
public GameServer(IGuildServer guildServer,
ILoginServer loginServer,
IRepositoryManager repositoryManager,
IFriendServer friendServer,
IGameConfiguration configuration, ...) {...}