Частично присоединяюсь к комментарии выше о том, что вполне себе уместно создать сущность Commentator и какие-либо. Да, можно на парится и везде использовать
userId, но тогда как получать список прав? Клонировать сущность User в контекст Статей? Но там может быть много "лишних" полей, вроде флага о двухфакторной авторизации, список привязанных аккаунтов из соц.сетей и прочее. Смысл DDD как раз в том, чтобы контекст Статей ничего этого лишнего и не знал, в том числе для упрощения модели.
Для простоты можно в контексте Статьи сделать "клона" User, в которой будут только необходимые поля для функционирования контекста Статьи.
> И четвертое: с тем что у меня получилось Author это агрегат, который имеет в себе коллекцию агрегатов Article, уместно ли такое решение?
Как будто бы не очень уместное, ведь в таком случае все сущности Article давнного автора будут доступны _только_ через агругат Author, что, пожалуй не очень удобно. Да и агрегат Author получится слишком тяжёлый, ведь для того, что бы тупо обновить имя автора нуобходимо будет всего автора, все его статьи и вообще всю информацию выгрузить в агрегат. Можно, но не рационально.
В "большой красной книге" Вернон как раз приводит аналогичный пример с сущностью Спринг и Таска для домена Скрам.
Если же мы просто будем хранить ссылки на статьи, тогда система получится более удобной. Но тут есть известный trade-off между полностой модили, чистотой модели и производительностью. Можно почитать вот тут на эту тему
https://enterprisecraftsmanship.com/posts/domain-m... 