DDD: создать хранилище для объекта и его статуса

Question

В моем домене есть субъект, которому нужно отслеживать его статус. И у меня есть обработчик для этого нужно. Этот статус похож на InProgress, Completed или Deleted. И я использую CosmosDb, SQL API для хранения этих данных.

Внутри CosmosDb я создал контейнер для этих созданных сущностей и другой контейнер для его статуса. Поэтому внутри кода у меня есть два репозитория для этих двух контейнеров.

internal interface EntityRepository
{
   Task AddAsync(Entity entity);
}

internal interface EntityStatusRepository
{
   Task AddAsync(EntityStatus entityStatus);
}

И для каждого репозитория я создал один сервис

public interface EnityService
{
    Task AddAsync(Entity entity);
}

public interface EntityStatusService
{
   Task AddStatusAsync(EntityStatus entityStatus)
}

Эти сервисы были представлены как открытые интерфейсы для обработчика, а не репозиториев.

СейчасМне действительно интересно

• Основываясь на DDD и имея сущность и ее статус, я должен создать два отдельных репозитория или они должны быть как один репозиторий, так как они представляют собой один контекст?

• Нужно ли раскрывать сущность и ее статус с помощью одной службы?

Интересно, есть ли у кого-нибудь предложение или даже лучшее решение?

Answer 1

Похоже, EntityStatus должен быть свойством Entity, но давайте рассмотрим логику, чтобы убедиться. Обратите внимание, что это не жесткие правила, просто мои эмпирические правила, когда я принимаю эти решения. Мои смягчающие обстоятельства меняют их.

• Должен ли EntityStatus быть совокупным корнем? Имеет ли смысл работать с EntityStatus отдельно, не связываясь ни с чем другим или только со ссылками на дочерние объекты? Если нет, то это не совокупный корень. Это означает, что это либо вспомогательная сущность, либо свойство.
• Если родительская сущность всегда имеет ровно одно текущее значение EntityStatus, и в статус не нужно встраивать логику, то лучше оставить ее каксвойство Entity.
• Если EntityStatus нуждается в встроенной логике, то, вероятно, это должен быть объект значения. Например, если состояние может изменяться только с X на Y в некоторых обстоятельствах, но не в других, или если какой-то внешний процесс должен запускаться при изменении состояния, это должен быть объект значения, значение которого устанавливается объектом. Быть объектом значения не обязательно означает, что это отдельная сущность.

Наконец, я предпочитаю привязывать свои репозитории к Агрегированным корням, даже если существуют объекты значений, принадлежащие AR. Обновление AR все должно быть сохранено или ничего, и расширение одной транзакции БД по репозиториям не является идеальным. Если вы используете шаблон «Единица работы», то обновление AR должно быть одной единицей. Я пытался создать отдельное репо для каждой таблицы, где репозиторий AR использует отдельные репозитории, и он чувствовал себя слишком гранулированным со всем каналом. Также было легко потерять бизнес-идею, которую вы пытаетесь воплотить, имея дело со всеми частями. В конце концов, однако, нет правила, регулирующего это, поэтому делайте то, что вы считаете правильным.

Answer 2

Я не эксперт по DDD - просто читаю Implementing DDD по Vernon, но по моему опыту у вас есть проблема с bounded context. Ваши модели Entity и EntityStatus, вероятно, тесно связаны. В этом случае вы должны создать EntityStatusRepository, только если у вас есть место, где вам нужно EntityStatuses. Если вам нужны оба, просто наберите EntityRepository