I'm somewhat inclined to agree with the single database argument here (the issues of backup & recoverability not withstanding).
But, the bigger question for me is the development and release cycle. These 8 different modules, are they being developed by a single team of developers on a single schedule? Just exactly how completely interactive are they? Sharing lots and lots of inter-dependent data, or just a few general lookups.
I had a system that, on the surface, sounds a lot like yours. So I made the decision to put it into a single DB. For terms of backup & restore and other general maintenance it's worked fine. It's also worked well for performance. But, with five different development teams making changes and releases on different schedules, we had HUGE bottlenecks on releases to production, testing, coding interdependencies that shouldn't have been there... Also, come to find out, the amount of information that was literally shared between these systems was minimal. The requirements gathering had, rather than look at the actual requirements of these systems, looked at a previous failed project that had put the data into overly protected individual silo's of information.
So, before you go down the single database route (which can work just fine), I would dig down a little further on the processes and business needs of the system, not the technology.
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore RooseveltThe Scary DBA
Author of: SQL Server Query Performance Tuning
and SQL Server Execution Plans
Product Evangelist for Red Gate Software