Headless eCommerce на Laravel: Погружение в модульную архитектуру

Да, это не репозиторий в чистом виде. Мы сознательно наделили его большей ответственностью, это во многом связано с модульностью.

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

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

Headless eCommerce на Laravel: Погружение в модульную архитектуру

Спасибо за вопросы.

Что внутри ModelInput

Все Input - это DTO, с дополнительной возможностью описания правил валидации и санитизации, тут можно провести аналогию с кастомными Request классами Laravel.

В ModelInput есть дополнительные системные свойства, например при описании правил валидации можно получить доступ к целевой модели.

Сами по себе Input классы ничего не делают.

Что внутри repository

Сложно так ответить, в статье есть описание того, что происходит в Repository при вызове save и find методов, это основные методы.

Попробуйте конкретизировать вопрос.

Как выбрасываются хуки таких составных сущностей (когда происходит создание сущности и изменение ее связей, но это один процесс как одно целое)

Используются те же инструменты, что и в стандартных Eloquent моделях, но добавлены еще свои события.

Для того, чтобы отслеживать изменения в связях модели, в базовом классе модели реализованы дополнительные методы:

wasRelationChanged - позволяет проверить были ли изменения в конкретной связи, по аналогии с wasChanged для атрибутов.

getRelationChanges - позволяет получить информацию об изменениях связи, зависит от типа связи, так для HasMany можно будет получить коллекцию удаленных/обновленных/созданных моделей.

Проверка прав

Есть несколько уровней проверки прав:

• Model level. Предназначен для ограничения доступа к модели в целом. Например, разные доступы для управления категориями в блоге и управления постами. Для реализации этого уровня достаточно указать разрешения в схеме модели.

• Row level. Предназначен для ограничения доступа к конкретным объектам модели. Например, авторы должны иметь доступ только к своим постам. Для реализации этого уровня необходимо написание политик.

• Attribute level. Предназначен для ограничения доступа к конкретным атрибутам модели. Для реализации этого уровня достаточно указать разрешения атрибутам в схеме модели.

Собственно, расширение, нет примера, как этот BlogPost может расширить другой модуль и использовать для какого-то другого use-кейса

Полноценного примера, который можно было бы пошарить, у меня сейчас нет.

Вот как это выглядит:

<?php
ProductOffer::extendSchema(static function (Schema $schema) {
    $schema->model(
        'reviews_rating',
        'Product review rating',
        ProductReviewRating::class,
        RelationResolver::create(static function (ProductOffer $offer): HasOne {
            return $offer
                ->hasOne(ProductReviewRating::class, 'product_id', 'product_id')
                ->withDefault();
        })
    );
});

В этом примере расширяется схема модели ProductOffer модулем product-reviews, само расширение реализовано в серсив провайдере модуля.

Headless eCommerce на Laravel: Погружение в модульную архитектуру

Хм, справедливо, в статье нет информации про устройство модульности, есть небольшая отсылка про Laravel, возможно стоило явно сослаться на Package Development. Цель статьи показать сложность, когда появляются зависимости между модулями, например модуль A расширяет модуль Б. Если у разработчика есть доступ к изменению обоих модулей, то наверно особых проблем нет, можно изменить модуль Б, так чтобы его можно было удобно расширить модулем А. Но это не то, что ожидаешь от модульности, т.к. нарушаются границы, разработка модуля А требует изменений в модуле Б. Если у разработчика нет доступа к модулю Б, тогда он ограничен заложенными в модуле Б точками расширения и событиями.