DDD: Къде да съхранявате интерфейсите на домейна, инфраструктурата?

Относно къде да поставя хранилищата, лично аз винаги поставям хранилищата в специален инфраструктурен слой (напр. MyApp.Data.Oracle), но декларирам интерфейсите, на които хранилищата трябва да отговарят, в слоя на домейна.
В моите проекти приложният слой трябва да има достъп до домейна и инфраструктурния слой, защото е отговорен за конфигурирането на домейна и инфраструктурния слой.
Приложният слой е отговорен за инжектирането на правилната инфраструктура в домейна. Домейнът не знае с коя инфраструктура говори, той знае само как да я извика. Разбира се, използвам IOC контейнери като Structuremap, за да инжектирам зависимостите в домейна. Отново не твърдя, че това е начинът, по който DDD препоръчва да структурирате вашите проекти, това е просто начинът, аз архитектурирам приложенията си. наздраве

Аз съм нов в DDD, така че не се колебайте да коментирате, ако не сте съгласни, тъй като вие съм тук, за да науча.

Лично аз не разбирам защо трябва да препращате към инфраструктурния слой от вашия домейн. Според мен домейнът не трябва да зависи от инфраструктурата. Обектите на домейна трябва да са напълно невежи в коя база данни работят или кой тип сървър за електронна поща се използва за изпращане на имейли. Чрез абстрахиране на домейна от инфраструктурата е по-лесно да се използва повторно; защото домейнът не знае на коя инфраструктура работи.

Това, което правя в моя код, е да препращам към домейн слоя от моя инфраструктурен слой (но не обратното). Репозиториите познават обектите на домейна, защото тяхната роля е да запазят състоянието на домейна. Моите хранилища съдържат моите основни CRUD операции за моите коренни агрегати (get(id), getall(), save(object), delete(object) и се извикват от моите контролери.

Това, което направих в последния си проект (подходът ми не е чисто DDD, но работи доста добре) е, че абстрахирах моите хранилища с интерфейси. Основните агрегати трябваше да бъдат създадени чрез предаване на конкретен тип хранилище:

Основният агрегат трябваше да бъде инстанциран през хранилище чрез използване на метода Get(ID) или Create() на хранилището. Конкретното хранилище, конструиращо обекта, премина само по себе си, така че агрегатът да може да запази неговото състояние и състоянието на неговите дъщерни обекти, но без да знае нищо за конкретната реализация на хранилището. напр.:

public class PostRepository:IPostRepository
{
     ...
    public Post Create()
    {
        Post post=new Post(this);
        dbContext.PostTable.Insert(post);
        return post;
     }
     public  Save(post)
     {
         Post exitingPost=GetPost(post.ID);
         existingPost = post;
         dbContext.SubmitChanges();
     }
}

public class Post
{

     private IPostRepository _repository
     internal  Post(IPostRepository repository)
     {
        _repository = repository;
     }
     ...
    Public Save()
    {
        _repository.Save(this);
     }

}

Бих ви посъветвал да обмислите Onion архитектура. Много добре пасва на DDD. Идеята е интерфейсите на вашето хранилище да се намират в слой точно извън домейна и да препращат директно към обекти:

IPostRepository.Save(Post post)

Домейнът изобщо не трябва да знае за хранилищата.

Инфраструктурният слой не се споменава от домейн или някой друг и съдържа конкретни реализации на хранилища наред с други неща, свързани с I/O. Общата библиотека с различни помощници се нарича Application Core в този случай и може да бъде използвана от всеки.