Considerations to architect well designed dependencies

I'm starting to consider implementing Inversion of Control containers in my future projects or refactorings and I was wondering which principles (besides GoF patterns) might be interesting to keep in mind when it comes to properly design dependencies. Say I need to architect a simple console app that will search for a book (by ISBN) in Amazon if it can a开发者_运维知识库ccess the internet or will fallback to a local database (SQLite, SqlServerCE) when there is no connection available. So the initial design might pretty much be:

• IAmazonSearchProvider
• ILocalSearchProvider
• IResultsGenerator (depending on either IAmazonSearchProvider or ILocalSearchProvider)
• IOutputFormatter
• ConsoleApplication (depends on IOutputFormatter)

Any guidance will be really appreciated, thanks a lot in advance.

That's a pretty normal approach, and it's not bad, but it focuses much on mechanics and may entail the risk of violating the Reused Abstractions Principle. At a high level, you'd be better off if you can make the API describe what it does instead of how it does it. Following the Hollywood Principle is an important start.

When designing abstractions, favor composition over inheritance. Apart from that, favor Role Interfaces over Header Interfaces.

Currently, I work with a loose ranking of Role Interface methods like this (where Commands are best):

1. Commands
2. Closure of Operations
3. Reduction of Input
4. Composable Return Types

I assume I* are interfaces. IResultsGenerator and ILocalSearchProvider sounds like implementations (and so not interfaces) of IResultsGenerator. Also something should depend on IResultsGenerator, I recommend it's ConsoleApplication.

The rest looks fine.