L' Eomot Inversé (7/10/2013)
I'm inclined to disagree with earlier comments. Look at your data and see what changes or grows rapidly, and what is pretty stable and changes less often and in smaller quantity. You need different backup strategies for the different chunks of data if there is a significant distinction in those issues, unless you have store to burn in which you can hold pointless backup data, and the easy way to handle that is to put data into different databases. Of course this classification of tables may match up with the multiple modules or (more likely) not since several modules may cause updates to the same data. The discussion of linked servers is a red herring, since that's a question of how you split your data between servers not of how you split it between databases, and the question was about splitting into databases.
+1000 to that. People just don't think about backups and the possible restores that go with them never mind thinking about static data that might only need to be backed up once per month and then only a part of that. It's not difficult to communicate between databases using SYNONYMs and there's virtually no performance hit.
--Jeff Moden
Change is inevitable... Change for the better is not.