When to separate code into new assemblies (DLL's)

Question

I work as part of a team creating an enterprise application that will be used in a new C# .NET Windows Application and a Web Application of the same. One of the other developers likes to separate things out into separate projects a bit more than I. His answer is always "separate of concerns" which I'm not sure I agree with.

My theory is you create separate assemblies when that code is capable of being shared by other consumers. Separation of concerns should be handled by namespaces. It can be an additional effort/challenge/nightmare to distribute an application with a large number of assemblies from versioning, obfuscation, etc. So it concerns me and I'm trying to find out what the rule of thumb is for when code is broken out into its own assembly.

What is your rule of thumb for separating code into other assemblies vs. using namespaces and other organization techniques within an application? Is there any guidance on this or patterns/practices that I can read to either say "yeah, he's right" or "please read this".

Thank you.

Answer 1

I think you have a communication issue, or an issue with nomenclature because, separation of concerns, generally means something different.

Strictly speaking, separation of concerns, deals with things like the single responsibility principle, in that, each class kinda deals with it's own domain. The single responsibility principle states that a class, should only have one reason to change.

Some examples of separation of concerns are view and model abstraction patterns such as MVC or MVVM. Where each component, be it the view or model, deals with user interface abstraction or data and validation, but not both.

Splitting up code into separate assemblies is a good practice when the code can be shared between multiple projects (like you yourself already pointed out). Simply structuring code can be done by using different namespaces.

When you have a lot of code, assemblies are a natural way of grouping code and when you managed code on different levels and have very controlled points of extensibility and want to lock that down, assemblies provide that level of isolation.