Где определить интерфейсы для репозитория в многоуровневой архитектуре?

Фон

Я пытаюсь создать простое приложение, чтобы действительно понять весь стек DDD + TDD + и т.д. Моя цель - динамически вводить классы репозитория DAL во время выполнения. Это помогает мне Доменные и прикладные службы. Я планирую использовать "бедного человека DI" для достижения это на данный момент... поэтому я бы сделал это в простом консольном приложении около запуска:

    // Poor man DI, injecting DAL repository classes at runtime
    var productRepository = new SimpleOrder.Repository.ProductRespository();
    var customerRepository = new SimpleOrder.Repository.CustomerRepository();
    var orderRepository = new SimpleOrder.Repository.OrderRepository();

    // Constructor injection into this class in the Application Services layer,
    // SimpleOrder.ApplicationFacade
    OrderEntry oe = new OrderEntry(customerRepository, orderRepository, productRepository);

Чтобы выполнить эту инъекцию зависимостей, я создал три интерфейса репозитория:

-- ICustomerRepository
-- IOrderRepository
-- IProductRespository

Типичная реализация:

    namespace SimpleOrder.Domain.Interfaces
    {
        public interface ICustomerRepository
        {
            Customer GetCustomerById(int customerId);
            void SaveCustomer(Customer customer);
        }
    }

** Обратите внимание, что SaveCustomer ссылается на класс модели клиента, определенный на уровне домена. Это типично для других репозиториев.

ОДНАКО Я не уверен, какой проект/слой они должны быть реализованы. У меня есть 5 проектов в решении:

• SimpleOrder.ConsoleClient(презентация) - Я хочу ввести конкретную реализацию домена отсюда как приложение

• SimpleOrder.ApplicationFacade(службы приложений) - мелкие более высокоуровневые, более грубые методы, организовывающие методы нижнего уровня в домене

• SimpleOrder.Contracts - классы DTO, используемые для связи между презентационными и прикладными службами

• SimpleOrder.Domain(домен/bll) - классы модели домена Customer, Order, OrderItem, Product

• SimpleOrder.Repository(dal) - реализует интерфейсы репозитория

Вот мои варианты, как я вижу:

Вариант 1: Определите интерфейсы репозитория в SimpleOrder.Contracts...

PRO: здесь я думаю, что они должны принадлежать, потому что я создал это для обмена контрактами между различными проблемами/слоями. например, DTO.

CON: однако метод signatures in каждого интерфейса ссылается на классы модели домена.
Это означает, что мне пришлось бы добавить ссылку на SimpleOrder.Domain, но когда SimpleOrder.Contracts ссылается в другом проекте, ему придется нести SimpleOrder.Domain для езды. Это не так.

Вариант 2: Тот же сценарий, что и выше, но я также определяю интерфейсы для каждой модели домена класса в SimpleOrder.Contracts, поэтому я могу разбить связь интерфейсов репозитория с фактическими классами моделей.

Пример:

    namespace SimpleOrder.Domain.Interfaces
    {
        public interface ICustomerRepository
        {
            ICustomer** GetCustomerById(int customerId);
            void SaveCustomer(ICustomer customer);
        }

        public interface ICustomer
        {
            int CustomerId { get; set; }
            string Name { get; set; }
            System.Collections.Generic.List Orders { get; }
        }
    }

IMPACT: каждому классу модели домена придется реализовать свой связанный интерфейс. то есть.,

    public class Customer : SimpleOrder.Domain.Interfaces.ICustomer
    {
        public Customer()
        {
            _orders = new List();
        }

        public int CustomerId { get; set; }
        public string Name { get; set; }

        private List _orders;
        public virtual List Orders {
            get { return _orders; }
        }
    }

PRO: Исправлена ​​проблема с параметром 1.

CON: Это взрывает количество файлов (и воспринимаемую сложность) в проекте, потому что каждый класс домена теперь имеет связанный интерфейс.

Вариант 3: Определите интервал хранилища в SimpleOrder.Domain

IMPACT: Чтобы внедрить конкретные классы репозитория в уровень сервисов приложений (SimpleOrder.ApplicationFacade project) из SimpleOrder.ConsoleClient во время выполнения, SimpleOder.ConsoleClient также потребуется ссылка на SimpleOrder.Domain.

PRO: Это ТАКЖЕ решает вариант 1

CON: Я пытался избежать ссылки на доменный уровень из уровня представления непосредственно, потому что теперь уровень представления может слишком много знать о домене. Когда я буду заменять консольное приложение в будущем с помощью WPF или ASP.NET MVC-приложения в будущем, я рискую реализовать второй и последующие реализации уровня представления, пытаясь вызвать методы в модели вместо уровня приложений. (Однако я рассматриваю это в Варианте 4.)

Вариант 4: Поместите интерфейсы в SimpleOrder.Domain, затем обратитесь к SimpleOrder.Domain из SimpleOrder.ConsoleClient.

PRO: Исправлены все вышеперечисленные проблемы.

CON: Это не очень хорошо, потому что я предоставляю доступ к уровню презентации непосредственно к методам нижнего уровня в доменном слое, когда я должен предоставлять только  доступ к более сложным методам более высокого уровня в SimpleOrder.ApplicationFacade.

Вопрос Я пробовал каждый из них, но решил, что на Варианте 4, ОДНАКО, это оставляет мне неприятный вкус. Есть ли лучший вариант? Я на правильном пути здесь?