У вас нет четкого понимания зачем нужен каждый из паттернов. Отсюда и вопросы куда их приткнуть.
Service это Transaction Script. Это бизнес-логика приложения, более относящаяся к бизнес-процессу, а не к поведению какой-то сущности. Дернуть, там, переложить сюда, принять решение и т.д. Есть у вас сложный бизнес-процесс?

Repository инкапсулирует сложные запросы.
Ваша фраза "который обращается к БД за составным запросом" смущает. К БД обращаются за данными, а не за запросами.
Есть сложные запросы? Фигачим их в репозиторий. Нет? Пользуем EM и не паримся.

Что за дублирующие методы и куда тут наследование, на пальцах совершенно не понятно.

Допускается делать всё что помогает организовать код и достичь требований SOLID и GRASP. Каждый паттерн это пример решения определенной проблемы. Это совершено не значит что нужно пихать его в каждый проект.

z3r9Blazkowicz, просто у меня такое представление что в слое Service должны быть все действия. То есть регистрация пользователя, удаление пользователя, подтверждение регистрации, получение данных пользователя по ID.
Я правильно понял что если процесс не сложный то не нужно его в слой сервис пихать. Например "получение данных пользователя по ID" можно брать напрямую с репозитория в JSF бине?

Хороший вопрос. Потому что я упустил из вида ещё и вторую роль Service. Он ещё и представляет из себя бизнес-фасад, на который можно навесить массу полезной функциональности
- Декларативную секурити (аннотации с ролями, которым доступно действие)
- Аудит (логирование действий пользователя)
- Поддержку других протоколов доступа к функциональности (SOAP, REST сервисы, любой другой ремотинг или интеграция)

Если у вас всё завернуто на сервисы, то вышеперечисленное не составляет вообще никакой проблемы. Если же существуют, как сервисы, так и прямые обращения JSF в ORM, то такие прямые обращения придется либо дублировать, либо всё равно выносить в сервис.