On (not?) splitting big .NET applications to assemblies

This only applies to .NET, and to large code bases fully controlled by you (preferably in a monorepo).

There are good dependencies, and bad dependencies.

Bad dependency

• Depends on a big framework (asp.net, wcf, ef, DI containers, etc.)
• Depends on several own assemblies
• Depends on a third party library
  • There are some exceptions in every product, e.g. NewtonSoft.Json, System.Reactive etc. can be "universal"
• Has significant business logic code
  • ...and therefore can change frequently

Good dependency:

• Is mostly declarations. POCOs, constants, enums, interfaces, attributes.
• Can be compiled in the beginning of your build.
• Can be compiled when your services are running (check OutputPath!)
• Doesn't change often. It's "ready".

You can bundle a lot of good dependencies together to same DLL without cost. If your DLL is less than 100kb, it's possible it
can be merged with other small DLLs to simplify your dependencies and speed up the build. Instead of Feature.Foo.dll and Feature.Bar.dll, consider if you could just have Feature.dll if those two libraries depend on same things.

Contrary to naive intuition, fine grained DLL's are not efficient and usually not desirable. You are not selling them separately, or distributing to other applications. When you need to add new DLLs (e.g. because it provides integration with some new third party library or service), consider if there are other DLLs you could get rid of in your code base.

You can add a reference to a good dependency without sweating it much. Most probably, you are already depending on it so you don't need to.

Namespaces for internal code don't really matter. Don't overbloat your pull requests by adjusting them constantly.

• ... except when they matter, and you have abominations like NetDataContractSerializer hiding somewhere. Stay safe!