Entity - сущность бизнеса. То, что еще называют "моделью", хотя этот термин так засрали, что лучше и не вспоминать про него. С чем работает наша проблемная область? С Клиентом, с менеджером, с заказов, с товаром - это и будут сущности. Важный момент - у сущности есть уникальный идентификатор.
Репозиторий - это коллекция сущностей, паттерн по управлению сущностями. Из репозитория мы их получаем, в репозиторий отправляем. Конкретная реализация репозитория на persistence уровне уже занимается сохранением и поиском сущностей в базах данных.
С аггрегатом и просто и сложно. Когда мы проектируем нашу предментую область, мы можем выделить такие сущности, которые не должны использоваться в отрыве от какой-то другой. Например, есть сущности "конкурс" и "фото на конкурс". Последняя не может существовать без конкурса, не может использоваться без него. При этом, именно "конкурс" мы будем спрашивать - сколько фото пришло. Удаляя конкурс - нужно удалить все фото этого конкурса. В таких случаях, мы определяем сводные (aggregate) границы и выделяем главную сущность (aggregate root или сводный корень). Ссылаться "извне", т.е. из других сущностей, не входящий в аггрегат мы можем только на сводный корень. Запрашивать из репозитория можем только сводный корень. И т.п., там много ограничений. Основная идея тут - инкапсулировать взаимодействие связанных сущностей внутри сводных границ, упростив таким образом глобальные взаимодействия.