What's the most important consideration when deciding how to partition your application into assemblies? Do some people just create one assembly per unique namespace (or perhaps per root namespace) for convenience? Or one per app-layer (like Presentation, Business/Services, Data)? Or more subtle perhaps, put the entire Model in one assembly? Does any of this really matter?
Does having too many assemblies slow things down, is there a critical mass or a "good" number of assemblies that an application should have? Likewise, is there a tipping point for when a single assembly is too big, and does a large assembly also affect performance?
I know it depends on the specific app of course – so I'm mainly interested in general guidelines, and what criteria to use when deciding.
(Although in my particular case, if anyone wants to comment on it, I'm building a WCF service with a business and DAL layer underneath, and a web site to consume the service. I've traditionally created lots of smaller assemblies, but now I'm thinking the simplicity of "Web", "Service", "Model" and maybe "Data" (for repositories etc) looks pretty appealing. Web references Service only, Service references Model only, and Model references Data only. Not sure how much it matters.)