In the current company that I work for there is a very large Utilities library.
ID: 642033 • Letter: I
Question
In the current company that I work for there is a very large Utilities library. It was written a few years back (long before I joined) and has grown ergonomically over time to now do everything:
Sending Emails
Exporting Files in different formats, i.e. CSV, tab delimited
Receiving data from 3rd party providers, i.e. Bloomberg, Facset
Sending files to SFTP sites
Generic database connection
The list goes on and it is pretty ugly really.
The original developer here used it in every application that he wrote for convenience sake and added to it as necessary. The utilities library itself has references to 3rd party API
Explanation / Answer
I would suggest that organization may be more important than separation. Separating things into separate DLLs could be useful when a client library only needs part (but not all) of the total functionality.
My suggestion would be to follow the DRY principle -- don't duplicate code. Shared code can be put into a base library that is shared among the more specialized ones. Just be careful that you don't get yourself into a dependency/DLL hell where you have to mess with an entire dependency tree...
To get around the DLL hell, I would recommend creating a single solution (.sln) file for the whole thing, then break down the separate DLLs as projects within it. That way you can rebuild everything at once, but still have some flexibility.
Another thought: as you work through your code base, you may find that organizing by business use case might not be as effective as by type of functionality or something else.