Currently I'm building a large framework whose purpose is to run several algorithms in sequence.
Many of these algorithms have interdependencies in data structure – the output of one algo is the input of another algo, for instance MagicVectorXY. The algorithms need to be modular and compact, because some of these algorithms will be reused in many other separate frameworks. And we want to avoid unreachable code as much as possible.
Our current solution is to compile each algorithm into its own .dll, while shared interfaces/3rd party math libraries/shared data structures reside in a CommonInterfaces.dll. However, this leads to proliferation of Projects in the Visual Studio Solution, and there's still significant unreachable code in the CommonInterfaces.dll.
What other strategies are there to manage such a modular framework?
PS: We foresee ~10 algorithms, and things like database layer, WCF, scheduling and Unit Tests for each project are all their own projects as well. So around 25-30 projects estimated in that single solution.
Best Answer
The information here is a bit scarce...
First of all (if you haven't already) you may want to check out SOLID. Follwing these rules will give your sofware a good dependency structure. A nice dependency structure is key to being able to swap modules in and out. (And you will not need to reference the datalayer to compile your algorithms)
What strikes me the most in your description is "shared interfaces". To make each algorithm a true module you want each module to individually define the interfaces it uses. See ISP. Then the implementation of the different interfaces can be in a single class that references the algorithm .dll:s but you can also provide different implementations for different frameworks if needed. Or maybe you have a default implementation that you can package with the module.
Also, don't be afraid to add projects. And I would recommend thinking about structuring the code by functionality (module/algorithm/etc.) instead of just different layers as that will allow you to for example pick the parts of the data layer you need.