A few months ago I published two articles on SimpleTalk on how to partition .NET code, first with assemblies, second with namespaces inside assemblies. I repackaged this content in two white books available in the NDepend documentation.
Partitioning .NET code is a topic that interests me for a long time. I consider it being the key to prevent code structure chaos (spaghetti) and to achieve higher code maintainability and quality. In the past years, on the present blog many posts about partitioning .NET code have been written, and these two white books represent the compilation of this content (8+7 printed pages).
When I browse the web, it seems to me that few developers question themselves about how to partition their .NET code base, through physical and logical components. It is commonly and tacitly accepted that the concept of VS project and .NET assembly is the right artifact to partition code and define components boundaries. But doing so leads to major frictions and productivity loss, like spending minutes to compile C# or VB.NET code instead of seconds. For the one that questions about how to partition code, there is a consequent Return On Investment waiting just here.
This topic involves many aspects of development. Hence choosing a way of partitioning code can only be the result of several choices and compromises. In the two white books the choices exposed are based on a simple idea: having as few assembly as needed (ideally one), each assembly being filled with several namespaces that represent the components boundaries, the namespaces’ dependency graph being acyclic. Doing so has proven being successful and cheap to achieve and maintain in many occasions (for example, see the recent Hendry Luk post on refactoring the SheepAop code base). I hope this content can be useful to you as well, and even if you don’t end up refactoring your code this way, you certainly won’t waste your time mulling over the ideal strategy you and your team should apply to partition code and avoid chaos.