dmitriy

DDD это больше про контекст чем про сущности, поэтому ваша модель должна быть в нескольких контекстах с разным поведением. Из описанной модели данных есть пользователь, заказ и скидка.
Если брать контекст заказа, то там заказ будет больше всего иметь атрибутов, поведения и тд, а скидка там будет слаба выражена. Но если перейти в контекст "Калькулятор скидки", то там сущность скидки будет центральной сущностью, остальные сущности будут иметь атрибуты лишь необходимые для данного контекста.
Почему отдельный контекст скидки? потому что чтобы ее рассчитать например не всегда и нужен заказ - скидка от группы пользователя (вип, гость и тд), местоположения, история заказов, категория купленных товаров и тд. В этом и преимущество от Service Layer, так как создав OrderService и метод calculateDiscount может получиться, что о заказе сервис будет знать совсем ничего, а вот от остальных сущностях очень много, а расположение уже определено.

1. Создал сервис ReportService. - правильное направление, но могут возникнуть проблемы когда ReportService использует UserService а UserService использует ReportService. Тут необходимо разделение сервисов на уровня приложения Aplication Services и доменных Domain Services, первые могут использовать domain services, вторые не должны использовать aplication services. Есть еще вариант организации бизнес логики через Command и Handlers.
2. DTO

1. Хорошо спроектировать, и держать систему на виду помогает Event Storming + miro
2. На выходе мы имеем команды, события, сущности(агрегаты), информация, контекст
3. В зависимости от приложения элементы с 2 шага преобразуются в код

1. mirro
2. draw.io отличный инструмент
3. https://sparxsystems.com/ для всех кейсов которые вы описали

Смотря для каких целей, понятно что в бд уникальный id, но для клиента может содержать что угодно, например id торговой точки + порядковый номер

DDD

И всю логику по обработки исключений запихнуть в класс MyException.
- не верно, логика обработки исключений должна быть в коде который использует ваш функционал и ловит эти исключения,
поэтому первый вариант

Прочитайте книгу "Чистая архитектура" (Р.Мартин), все встанет на свои места.
Контракт - не может быть реализацией, это абстракция. Применяется тогда когда планируется менять реализацию (конкретику) контракта по мере эксплуатации системы, обычно в долгоиграющий проектах.

Абстрактный класс - это родительский класс который дает своим предкам что то общее + необходимость реализации своего контракта, но он относится к конкретике, а не контракту.

направление верное
в данному примере SelectUsers это солянка из
это UserRepository и PurchaseRepository
по принципу единственной ответсвенности нужно разнести по этим двум классам

соответсвенно контроллер будет

class TestController extends Controller
{
 protected $purchaseRepository;
   public function __construct(PurchaseRepositoryInterface $purchaseRepository){
$this->purchaseRepository = $purchaseRepository;
   }
    public function index()
    {
        $purchase = $this->purchaseRepository->selectpurchase(2);
        dump($purchase);
    }
}

по организации бизнес логики, можно в сервисы, но опять же эти сервисы удобно сформировывать от use cases а не от сущностей, поэтому формируются такие классы и методы:
Shopping->addItemToShoppingCart()
Shopping->remoteItemFromShoppingCart()
Shopping->checkout()
Searching->searchByAuthor()
Searching->advancedSearch()

или же на каждое действие свой класс, паттерн команда
Shopping/AddItemToShoppingCart
Shopping/RemoteItemFromShoppingCart

я бы воспользовался путем создания репозитория на том же github, gitlab
пример https://github.com/domnikl/DesignPatternsPHP

в вашем случае по типам классов: Helpers, Configs, Exceptions,
Классы которые носят универсальный характер и не связанны с приложением, как правило в /vendor/{your_company}/{project}
как упомянули выше

как правило Repository - уровень инфраструктуры а не домена, с доменом они связанны интерфейсами.
например доменная сущность (по сути это BLL):
Domains/User/User
Domains/UserCollection
Domains/User/RepositoryInterface (возвращает User, UserCollection)

Инфраструктура:
Infrastructure/User/Repository (реализует RepositoryInterface, работает с бд, использует DAL, mapping)

ну и Application
контроллеры, GUI , views

больше да чем нет

Может здесь что то будет полезно https://github.com/dimaxz/Lectures?files=1

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

Репозиторий это слои отделяющий приложение от хранилища, через этот слой проходят сущности (Entity) при сохранении, обновлении на входе и сущности и коллекции сущностей на выходе (Entity,Collection).
Репозитрии работают с драйвером бд и с маппером.
Именно на такой реализации я пока остановился

нагуглил, что вроде как паттерн мост подходит, пример в php-debugbar https://github.com/maximebf/php-debugbar/tree/mast...
https://sourcemaking.com/design_patterns/bridge/php