Where to store Interfaces in a Decoupled Architecture in my C# Solution?

Question

I know this question might seem to be answered before, but I feel that the answer varies from case to case, so after reading several posts, I'm not sure in my case which is the best for my architecture.

I have a Component Library that has a Data Model and basic functionality that should be available to any application implementing this component.

I have a boundary for this component which has an interface IReader to load and process files from the disk and IDataMapper to provide Database access and CRUD operations. a few other interfaces for specific functionality like IObjectComparison to compare objects, IXMLSerialization fro XML serialization.

I'm not sure where to store the definition of these interfaces.

The options are:

1)- Within the core Library, then when I write the implementations I will have to include the implementation libraries within this core component with I'd like to maintain decopled from the implementations.

2)- In a separate library project (Assembly). All interfaces there and included to the core component and included by the implementation libraries.

3) - In the implementation Libraries, then the core component will have to include the implementation libraries.

The only case where it seems reasonable decoupled is if I put all interfaces in a separate assembly library where Core component includes and any implementations I might need.

What do you guys think are Pros/Cons of the best option? All I want to achieve is a decoupled architecture.

So when I do

Constructor:

CoreComponent(IReader Reader, IDataMapper Mapper)

new CoreComponent(WindowsReader, SQLServerMapper)

and don't have to include WindowsReader or SQLServerMapper into the Core Component

Cheers.

Answer 1

I would go for option 1 - Core Library as it is accordance with how we do in DDD . In DDD we used to put IRepository interfaces in Domain Layer instead of DAL or any other such layer.

DIP says the higher level component would own the interface, as Wikipedia says...

where interfaces defining the behavior/services required by the high-level component are owned by, and exist within the high-level component's package.

This is most common practice but not a strict rule.

Option 2 is fine but you need to refer two DLLs in other projects but with option 1 only one reference is needed. Option 3 is not appropriate.

Hope it would help. Thanks.