Assembly cohesion
Assembly cohesion can be a bit of a red herring-it diverts attention away from assemblies' inherent features as a deployment strategy. Breaking up a solution into multiple assemblies simply to give related types a cohesive place to live is not the intention here. Assemblies are a deployment strategy; assemblies may need to exist for specific reasons unrelated to cohesion. For example, if two groups of different code need to be executed in separate processes or on separate computers, they need to live in different assemblies regardless of whether their packaging together would be more cohesive.
If you're restructuring a system at the assembly level, you've got some pretty specific needs for what is contained in what assembly. That's not to say you won't have multiple assemblies per deployment platform. You may want to have assemblies that are shared amongst multiple applications, and they may need to be highly cohesive. .NET is a good example of this. .NET 2.0 deployed a certain set of assemblies. .NET 3.0 added types and features, but they're primarily added to assemblies new to .NET 3.0 to avoid changing existing binaries. For example, types in the System. Data.Linq namespace could have been included the System.Data.dll assembly and that assembly would have still been cohesive. But, because of the deployment issues (where System.Data.dll shouldn't be modified for anything other than show-stopper bugs) added, LINQ types and features were added to a new assembly: System.Data.Linq.dll.