Мысли в слух:
Контроллер пользуется слоем валидации для проверки данных, если данные валидны он посылает их в нужный акшен.
Пример:
Форма регистрации посылает данные в RegisterController. токо он знает как валидировать эти данные (например есть ли там каптча или проверка пароля в двух филдах), тем самым он проверяет данные и потом уже валидные данные посылает в ActionCreateUser. Это позволяет быстро создать и другие методы для создания юзера, например через форму в админке (там уже не будет каптчи) или через файл экселя, у каждого такова метода свой контроллер и набор правил для валидации, но уже валидные данные они отпровляют в тот же акшен.
==Edit==
Репозиторий не всегда должен быть 1:1 с БД. Пример:
UserEntity и ActivationCodeValueObject
ни что не мешаеть сделать две таблицы в БД: Users, ActivationCode но репозиторий будет один UserRepository который будеть делать join чтобы вернуть UserEntity с ActivationCodeValueObject.
ИМХО это очень правильно. Сам маялся как сделать пока не осознал что репозиторий это не 1:1 mirror таблиц в БД а всего лиш хранилище данных. А как эти данные хранатся в одной или в 10 таблицах, ему пофиг он просто должен знать как из этих данных вернуть полноценный энтити.
==Edit==
Проектируя систему ДДД не думайте в понятиях базы данных! Это не првильно. Пример:
Логично что Identity User-а это ID из БД, но потом я подумал как реализовать User::factory(...) он не создает запись в БД, а просто делает new User(..); но у каждого энтити должен быт Identity, а как мне знать АйДи если я не пишу в БД?! Так вот дорогие мои, Identity User-а это не АйДи из БД, а email в моем случаее, АйДи в БД это просто для удобства связи и быстрого поиска. Вот так вот.