Q:

Multiple DLLs for one layer

I usually split projects into layers i.e. presentation layer, business logic layer and data logic layer.  Sometimes I will separate the layers using namespaces and sometimes I will have three separate DLL's (using tiers).
I see developers splitting tiers into multiple DLL's.  For example, I once saw a business logic layer with over one hundred different project files and hence over one hundred different DLLs.  Also the MSDN documentation shows that the .NET framework contains multiple DLL's e.g. mscorlib etc.  
I believe that the reasoning behind having separate DLLs is that it minimizes the memory footprint and also it allows multiple developers to work on different projects e.g. one team could work on one project and another team on another project etc.
I work in a two developer team.  What criteria do developers use deciding to split into separate DLLs?

A:

Separating code into more than one assembly is done for many reasons, some more technical than others. Assemblies can be used for logical grouping of code much like namespaces and, in fact, one common pattern is to separate large namespaces (concerns) into separate assemblies for that namespace. But that reason is most definitely not the best reason to use more than one assembly. 
Code reuse is like the number one factor for placing code into different assemblies. For example, you may have a console application and all of the code in is the one execute file that is compiled. Later on, you decide to create a web app front-nd for the same application. Instead of copying the core code from your console app to your web app, you would likely refactor the solution into three projects: a class library for the code code (the main implementation), a console app (which already exists) and a web app. The console app and web app projects/assemblies will reference the class library project/assembly and the main code is reused across both implementations. This is an oversimplification, mind you. 
Another reason to separate code into multiple assemblies to separate concerns while managing dependencies. In this case, you may have code that requires references to web-oriented dependencies (other assemblies) that you may not want to reference in your core application assemblies. You would do that so that you may reuse your core assemblies without taking unnecesary dependencies  when they are not needed by breaking up the app into additional assemblies/projects.
Another reason is to facilitate concurrent development of a large team where sub-teams may each work on a different assembly, helping to reduce the number of "collissions" between developers working on different concerns of the application.

