DDD: Где сохранить домен Interfaces, Инфраструктуру?
Вы можете использовать PersistentVolume и PersistentVolumeClaim для этой цели. Это решение, предлагаемое k8s для постоянных данных. Запишите все данные в PVC, которые вы не хотите потерять, даже если все капсулы умирают. Также данные, записанные в PV, могут быть переданы pod как volumeMounts. Существует несколько способов создания PV и PVC, таких как hostPath, NFS и т. Д. Вы можете проверить документацию k8s для получения более подробной информации и подходящего типа PV для вашего случая использования.
3 ответа
Eric, я отсутствовал для пары, поэтому прощает мне за ответ настолько поздно. Касающееся, куда поместить репозитории, лично я всегда, помещало репозитории в специализированный уровень инфраструктуры (например, MyApp. Данные. Oracle), но объявляют интерфейсы, к которым репозитории должны соответствовать в доменном слое.
В моих проектах Прикладной уровень должен получить доступ к Доменному и Уровню инфраструктуры, потому что это ответственно для конфигурирования доменного и уровня инфраструктуры.
Прикладной уровень ответственен для введения надлежащей инфраструктуры в домен. Домен не знает, к которой инфраструктуре он говорит, он только знает, как назвать его. Конечно, я использую контейнеры МОК как Structuremap для введения зависимостей в домен. Снова я не заявляю, что это - способ, которым DDD рекомендует структурировать Ваши проекты, это - просто путь, я архитектура мои приложения.Удачи.
Я тих новый в DDD, поэтому прокомментируйте, не соглашаетесь ли Вы, как Вы я здесь для изучения.
Лично я не понимаю, почему необходимо сослаться на уровень инфраструктуры от домена. По-моему, домен не должен зависеть от инфраструктуры. Объекты области должны быть абсолютно не осведомлены, на которой базе данных они работают или какой тип почтового сервера используется для отправки писем. Путем абстракции домена от инфраструктуры это легче к повторному использованию; потому что домен не знает на который инфраструктура его выполнение.
То, что я делаю в своем коде, является ссылкой доменный слой от моего уровня инфраструктуры (но не противоположное). Репозитории знают объекты области, потому что их роль состоит в том, чтобы сохранить состояние для домена. Мои репозитории содержат мои основные операции CRUD для моего корня, агрегируется (получите (идентификатор), getall (), сохраните (возражают), удаляют (возражают) и названы из моих контроллеров.
То, что я сделал на своем последнем проекте (моим подходом не является просто DDD, но он работал вполне прилично), - то, что я абстрагировал свои Репозитории с интерфейсами. Корень агрегируется, должен был быть инстанцирован путем передачи конкретного типа Репозитория:
Корневой агрегат нужно было инстанцировать через репозиторий при помощи Получить (идентификатор) или Создавание () метод репозитория. Бетонный Репозиторий, создающий объект, передал себя так, чтобы агрегат мог сохранить его состояние и состояние его дочерних объектов, но не зная ничего конкретной реализации репозитория. например:
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)
Домен не должен знать о репозиториях вообще.
На уровень инфраструктуры не ссылается Домен или кто-либо еще и содержит конкретные реализации репозиториев среди другого материала I/O-related. Общую библиотеку с различными помощниками называют Ядром Приложения в этом случае, и на нее может сослаться любой.