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);
     }

}

Я бы посоветовал вам подумать о луковой архитектуре. Он очень хорошо сочетается с DDD. Идея состоит в том, что интерфейсы вашего репозитория находятся на уровне за пределами домена и напрямую ссылаются на сущности:

IPostRepository.Save(Post post)

Домену вообще не нужно знать о репозиториях.

Уровень инфраструктуры не упоминается ни доменом, ни кем-либо еще и содержит конкретные реализации репозиториев среди прочего, связанного с вводом-выводом. Общая библиотека с различными помощниками в этом случае называется Application Core, и на нее может ссылаться кто угодно.