Resources for designing .dll structure

Question

I just came out of a design meeting and had a question posed to me about where I got one of my ideas about how to structure some .dlls of a project we are building. To be honest I have no idea where this "idea" came from it just seemed like natural knowledge to me. However it would useful if I could back up these opinions with some documented analysis.

Does anyone know of any resources that explicity discuss different mechanisms for structuring assemblies/modules/source?

UPDATE:

Well the idea was nothing special. We were discussing an abstraction layer for some hardware so the "app" that consumes these services could be (sort of) platform independant. Previously we've had an interfaces .dll that declares the interfaces the app requires and an implementation .dll that implements them for the one platform we've had thus far. Now we have two platforms but they are very similar. To prevent the interfaces .dll from being polluted or some hideous scenario where the implementations reference one another I merely suggested we create another .dll that sits between the interfaces and specificplatform.dlls where common abstract implementations can live.

Answer 1

If you have a chance, have a look at the book by Robert C. Martin:

Agile Principles, Patterns, and Practices in C# (This is the new version specifically targeted to .Net)

There is a chapter dedicated to component design that (probably) answers your question.

In summary, and after reading that book, I always recommend separating components by these criteria:

• Assemblies are units or reuse: If there are classes that have to be used together, they go in the same assembly.

• Assemblies are units of change: If there are classes that do not have to change for the same reason, they probably should not be in the same assembly.

• Assemblies are units of deployment: If there are classes that have to be physically deployed in the same place, they probably should go in the same assembly.

Of course these are just heuristics and not recipes. You eventually need to decide how much of each one of those three design heuristics you need based on the architectural goals of your application (specifically the architectural goals for deployment and evolution/modification).