DDD дизайн и HttpDelete

Question

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

Допустим, я хочу удалить рецензию на пост.Здесь, насколько я понял, пост является root.Поэтому все общение с рецензией должно осуществляться через почтовый объект.Это означает, что мне нужно получить как идентификатор агрегатного корня, так и идентификатор агрегатного объекта в качестве параметров запроса на удаление HTTP?

Answer 1

Это было бы более практично, но вам это не обязательно.Ваш REST API не обязательно должен быть точным отражением вашей доменной модели - HTTP и DDD - две совершенно разные парадигмы со своими собственными ограничениями и представлением о мире.

Допустимая альтернатива - получение правильнойPost, основанный исключительно на ReviewId и попросить, чтобы Post удалил Отзыв

DELETE /reviews/1234

...
post = postRepository.getPostForReview(reviewId);
post.deleteReview(reviewId);

, хотя я согласен, что в данном конкретном случае DELETE /posts/1234/reviews/5678, вероятно, является лучшим URI.

Answer 2

Это означает, что мне нужно получить как идентификатор агрегатного корня, так и идентификатор агрегатного объекта в качестве параметров запроса на удаление HTTP?

Краткий ответ: да.

Несколько более длинный ответ: чтобы взаимодействовать с сущностью, которая подчинена агрегированному корню, вам нужно направиться к корню (так вам нужен Id), и вам нужно передать корню в качестве аргументов необходимую информациюуказать целевой объект.

DELETE не поддерживает тело запроса;поэтому аргументы должны быть чем-то, что исходный сервер может восстановить только из URI (либо аргументы закодированы в URI, либо URI дает вам доступ к ресурсу, который знает, что это за аргументы).

Примечание: не сразу очевидно, что Review должен быть подчиненным объектом в совокупности Post.Совокупный дизайн о поведениях не отношениях .Если моделирование Review как отдельного агрегата из Post облегчает вашу жизнь, вам следует подумать об этом.