Architecting/Maintaining/Deploying large applications

Question

Here at work we have a very large application with multiple sub applications. (500 + dlls)

As a developer it is very frustrating working with all these dlls and dependencies. You create a new project and add 5+ dlls to get core pieces of the system to work (Logging, Auditing, security, messaging ect). Each new subapplication we add, we make a web project, a business layer, a data layer and any other projects needed to share objects between the 3, so our list just keeps expanding.

My question is what is the best way to manage this? i can't seem to think what is best.. the modular approach seems good for re-usablity, and hot patching items without taking down the system for one application. But the headache in managing 500 dlls is a nightmare.

Does each subsystem really need 3-4 projects, and reference the other 5 core pieces?

What are other ways of managing large projects keeping managing/developing and deploying in mind?

Answer 1

I have very good experience with naming guidelines in all types of projects (currently I working on 250+ dlls project). If you (or anyone else) choose good naming conventions, you see on first look what "it" is and you know how named is something you need.

Don't worry about count of references in project. If you are frustrated of adding X references every time, you can create a macro which will do it instead you. Or you can create a template VS solution/project/items(files) with your special requirements.

The large projects are large, so it's not surprise, if you must working with large amount of dlls, classes, etc...

Answer 2

It's an ongoing battle. Our system has about 100 different projects: mostly C#, with a few C++ projects for low-level stuff. If we add a new C# project we have to add references to a half dozen other projects, just to get base functionality.

In your example, you say that for each subapplication you make three or more projects (web project, business layer, data layer, etc.) Although we create those layers, we try as much as possible to keep them in the same project, specifically to avoid adding unnecessary projects. We won't break a subapplication into different projects unless it's going to be spread across multiple processes, or if we know that other pieces of the overall system will need to communicate with that subsystem.

It's likely that each subsystem really does need to reference the core pieces. Whether or not it needs 3-4 projects depends on how you've architected it. We've found that limiting new project creation to pieces that communicate with other projects or are used by multiple subsystems has greatly reduced the number of projects that we have to contend with.