Separate usage-specific interfaces into an "Abstractions" NuGet package

[craigfowler]

It's becoming increasingly popular within NuGet packaging to separate dependencies which are often used in a cross-cutting way into two separate packages. One of those packages is very small and contains just the abstractions required to consume the functionality via dependency injection. The other package contains all of the logic. The larger package needs be consumed as a dependency only in projects which need to either configure dependency injection or configure the dependency itself. Microsoft have been adopting this in their Microsoft.Extensions.* packages; many of those have an accompanying Abstractions package.

I feel Automapper is a fit where this kind of technique would be useful. Projects which use Automapper tend to consume its functionality from many layers of their architecture and its usage does not usually match just one part of the business domain. So, similarly to the MS Extensions packages, I think that it would be useful for Automapper to provide an abstractions package. That package would contain just the interfaces required for a .NET project (which is assumed to be using dependency injection) to inject an IMapper and make use of it, without depending upon the whole of Automapper's main logic package.

Potential payoff

Whilst this abstraction will not mean "we are abstracting from Automapper itself", an abstractions package is far less likely to need version changes than the main library; presumably the IMapper interface does not change very often. Thus, projects which only consume an abstractions package are protected from most of the concerns of version changes.

It would also allow developers to isolate logic which has a "hard dependency" upon all of Automapper (for example, their Profile classes) into specific projects, reducing the overall surface area of that dependency to only those projects.

Without this (workaround)

Without this, I'm frequently inclined to abstract away from Automapper myself, because I don't want to weave a hard dependency upon the Automapper package through my core business logic. Whilst it's only a case of creating my own IMapper interface, it's pretty much a copy-paste of the Automapper one. I expect that I'm not the only developer who does this.

It would be convenient if I could just consume an abstractions package, and then I don't need to write my own boilerplate mapping interface.

For solutions which do not use DI

Solutions which are not using DI, or those for which the techniques described above do not help, are free to consume the main logic package (equivalent to the current Automapper package). The main/logic Automapper package would have its own dependency upon the abstractions package in this way, so nothing would differ for those solutions.