Как правильно спроектировать Laravel приложение с уклоном в enterprise?

Вообще-то работа с ActiveRecord в экшене возможна в простых приложениях

Для сложной бизнес логики создаются слои поверх.

В Laravel используются отдельные компоненты Symfony

Вопрос же целостности данных решать на уровне PHP не имеет смыла.

> Читайте вопрос автора.

> Поверх чего? Поверх ActiveRecord? Зачем он тогда нужен во фреймворке, если есть DataMapping?

> Значит Larvel не написан на основе Symfony. А написан с использованием компонентов Symfony. Но, суть Фреймворка именно в предложении концепции программисту как строить своё приложение.

Так что решать проблему целостности данных, вы будете частично в приложении. И так делают 99% разработчиков.

Эра быстрых прототипов закончилась, где то в 2012. Сейчас уже нужны комплексные решения.

Первое что я вижу в этом Фреймворке, что большая часть работы каркасных компонентов завязана на статических вызовах.

Далеко за примерами{ссылка} ходить не нужно, уже треш.

Все это предлагается зашивать прям в контроллерах, с помощью protected или private методов.

Они написали универсальный DI Container и кладут в него все что угодно, используя в качестве идентификатора строчку.
Строчку, М**Ь ЕЁ! Не интерфейс — строчку!

И вообще один сквозной dic через все приложение - плохо.

Почитайте у Фаулера как нужно делать dic.

И да, нужно получать реализацию по интерфейсу.

Какую предлагает symfony? )

Я написал развернуто, почему нельзя писать на ларвел

Так и определитесь, возможно использование ActiveRecord в экшенах.

Бизнес - это больше чем заполнение полей данными. Если вы не заметили, то топикстартер упомянул DDD.

А вот фреймвок Laravel сверху их организует и создаёт флов разработки,

Но не интерпрайз. А теперь и биг дата, понимаешь.

Предварительная валидация данных - это не целостность данных

Если БД построена не для интерпрайза

В чем проблема?))

Почитайте %FamousName% как нужно делать %Anything%. Давайте конкретней, что не так и почему это плохо))

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

Обычное SOA

Это фасады - от них можно и стоит избавиться, это не работа со статическими методами объекта в прямом смысле.

К чему этот пример, что это вообще за сайт.

Кто такое предлагает?

Планируем начинать новый проект и хотелось бы организовать структуру с учётом лучших практик

все ваши доводы в рамках разработки на Laravel решаемы, и топикстартера как раз интересует, как это сделать.

От роутинга тоже можно избавиться?
От ActiveRecord (подключения к БД)?
От Events?

Нашёл типичный пример контроллера на laravel. Если у вас есть другой — приведите.

Что-то не вижу вашего ответа от вас о том как решить. Даже проблематики не описали. Мне кажется, вы не обладаете знаниями и просто генерируете пустые байты.

конечно от этого всего,

контроллер максимально простой

zugo в своем ответе написал описал проблематику

оффтопят, предлагая другие инструменты.

Зачем тогда этот Фреймворк брать вообще?

Давайте что-то во флоу laravel, где есть хотя бы обработка формы и работа с БД.

вы не понимаете что такое в принципе Фреймворк(см выше)
И если всё выбросить из Фреймворка

Как вы предлагаете прозрачно внедрить RBAC в приложении на laravel? Какой подход предлагают авторы Фреймворка?

Еще раз, не предлагаю я ВСЕ выбросить, просто утверждаю, что некоторые вещи, особенно фасады, надо выбросить.

Проблема Laravel в рамках темы обсуждения в том, что в документации нет информации о том, где хранить логику,

Instead of defining all of your request handling logic as Closures in route files, you may wish to organize this behavior using Controller classes. Controllers can group related request handling logic into a single class. Controllers are stored in the app/Http/Controllers directory.

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

«Фреймворк» отличается от понятия библиотеки тем, что библиотека может быть использована в программном продукте просто как набор подпрограмм близкой функциональности, не влияя на архитектуру программного продукта и не накладывая на неё никаких ограничений. В то время как «фреймворк» диктует правила построения архитектуры приложения, задавая на начальном этапе разработки поведение по умолчанию — «каркас», который нужно будет расширять и изменять, согласно указанным требованиям.

Другим ключевым отличием «фреймворка» от библиотеки может быть инверсия управления: пользовательский код вызывает функции библиотеки (или классы) и получает управление после вызова. Во «фреймворке», пользовательский код может реализовывать конкретное поведение, встраиваемое в более общий — «абстрактный» код фреймворка. При этом, «фреймворк» вызывает функции (классы) пользовательского кода

Route::get('products', [
    'as'   => 'products.show',
    'uses' => 'ProductController@products',
]);

Route::get('product/{product}/', [
    'as'   => 'product.show',
    'uses' => 'ProductController@product',
])->where('product', '[0-9]*');

Route::get('cart', [
    'as'   => 'cart.show',
    'uses' => 'CartController@show',
]);

Route::post('cart/{product}/{action}', [
    'as'   => 'cart.change',
    'uses' => 'CartController@change',
])->where([
    'product' => '[0-9]*',
    'action'  => 'append|reduce|clear',
]);

<?php namespace App\Http\Controllers;

use App\Product;
use App\Cart;

class ProductController extends Controller
{
    const ITEMS_ON_PAGE = 10;

    public function products()
    {
        $products = Product::orderBy('price', 'desc')
            ->paginate(self::ITEMS_ON_PAGE);

        if (!count($products)) {
            // Как вариант, решать в отображении что сообщить, 
            // так как может не быть товаров вообще
            abort(404);
        }

        return view('product.list')
            ->with('products', $products)
            ->with('cart', Cart::summary());
    }

    public function product($productId)
    {
        $product = Product::find($productId);

        if (!$product) {
            abort(404);
        }

        return view('product.item')
            ->with('product', $product)
            ->with('cart', Cart::summary());
    }
}

<?php namespace App\Http\Controllers;

use App\Cart;
use Illuminate\Support\Facades\Log;

class CartController extends Controller
{
    public function show()
    {
        return view('cart.show')
            ->with('cart', Cart::all());
    }

    public function change($productId, $action)
    {
        try {
            // Изменение корзины внутреннее дело самой корзины
            Cart::change($productId, $action);
        } catch(\Exception $e) {
            // Здесь можно разрешить как не стандартные ситуации, так и стандартные.
            // Но у нас пока одно.
            Log::error('Cart change: ' . $e->getMessage(), [$productId, $action]);

            return back()
                ->with('message', 'Простите, дяденька, засранца.');
        }

        // Возвращаемся туда от куда добавился товар или изменилось его количество.
        // А именно страница товара, списка товаров или корзина.
        return back();
    }
}

Вы вообще на что это пишите? Я вас спрашиваю, поверх чего создаются слои и для чего.

// ...
Route::post('cart', [
    'as'   => 'cart.change',
    'uses' => 'CartController@change',
]);

<?php namespace App\Http\Controllers;

// Для папки App\Http\Requests\ валидируемые запросы идут из коробки, 
// но требуют определения
// Например, реализуем проверку параметров сортировки
use App\Http\Requests\CartGet; 
// Здесь проверяем product_id и action
use App\Http\Requests\CartChange; 

// Наши реализации для DDD, которые работают с ActiveRecord
use App\Domain\Cart\GetRequest;
use App\Domain\Cart\ChangeRequest;

use Illuminate\Support\Facades\Log;

class CartController extends Controller
{
    public function show(CartGet $request)
    {
        $cart_request = new GetRequest($request);
        $cart = $cart_request->process();

        return view('cart.show')
            ->with('cart', $cart);
    }

    public function change(CartChange $request)
    {
        try {
            $cart_request = new ChangeRequest($request);
            $cart_request->process();
        } catch(\Exception $e) {
            // Здесь можно разрешить как не стандартные ситуации, так и стандартные.
            // Но у нас пока одно.
            Log::error('Cart change: ' . $e->getMessage(), $request);

            return back()
                ->with('message', 'Простите, дяденька, засранца.');
        }

        // Возвращаемся туда от куда добавился товар или изменилось его количество
        return back();
    }
}

<?php namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class CartChange extends FormRequest
{
    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        return [
            'product_id' => 'required|exists:products,id', 
            'action'     => 'required|in:append|reduce|clear',
        ];
    }

    public function messages()
    {
        return [
            'product_id.required' => 'Не выбран товар.',
            'product_id.exists'   => 'Товар не доступен.',
            'action.required'     => 'Не выбрано действие над товаром',
            'action.in'           => 'Не верное действие над товаром',
        ];
    }
}

Вы хоть раз принимали участие в большой разработке?

Если выбросить все на статиках, от Фреймворка останется одно название.

Фреймворк, это платформа, которая предлагает пути решения задач.
Если для решения задач, нужно выкинуть часть элементов Фреймворка, то он не предлагает решения для этой задачи.

Строго говоря, он предлагает это делать в контроллерах

RBAC будет решена на основе private и protected методов класса. По другому это вы не сделаете.

Как только вы выбрасываете часть Фреймворка, он, по сути, становится либо другим Фреймворком(самопалом) либо библиотекой.

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

Роутинг, работа с БД, да и все остальное останется.

Нет никаких готовых решений для построения сложных Enterprise приложений

Ок, предлагает, был не прав. Но не обязывает и делать этого не следует.

По-моему можно сделать как угодно, как раз Laravel позволяет делать все, что угодно, вклиниваясь в любую часть работы.

Фреймворк остается самим собой, просто не используется часть его функций

Т.е. фреймворк расширяется и изменяется согласно требованиям разрабатываемого приложения.

если не использовать методику предложенную Фреймворком, то по сути, вы используете его как библиотеку и он вам только мешает.

Ещё раз прочитайте определение Фреймворка вдумчиво. Фреймворк предоставляет методику написания приложения на нём и вызывает ваш код (который написали вы).

пример, как вы организуете передачу соединения с БД в экшен и сделаете проверку прав на то, что пользователь имеет право получать данные для определённого company_id

$company = auth()->user()->company()->where('id', request('company_id'))->firstOrFail();

Вы уже из-за подхода Laravel начали во всю использовать статики: Card::change Log::error

class CartController extends Controller
{
    //...
    public function change($productId, $action)
    {
        try {
            $session_id = session()->getId();

            $cart = Cart::bySession($session_id)
                ->firstOrCreate(['session' => $session_id]);

            $cart->change($productId, $action);
            
        } catch(\Exception $e) {
            // Здесь можно разрешить как не стандартные ситуации, так и стандартные.
            // Но у нас пока одно.
            Log::error('Cart change: ' . $e->getMessage(), [$productId, $action]);

            return back()
                ->with('message', 'Простите, дяденька, засранца.');
        }

        // Возвращаемся туда от куда добавился товар или изменилось его количество
        return back();
    }
}

namespace App;

use Illuminate\Database\Eloquent\Model;

use App\Cart\ActionException;

class Cart extends Model
{
    // ...
    public function scopeBySession($query, $sessionId)
    {
        return $query->where('session', '=', $sessionId);
    }

    public function change($productId, $action)
    {
        switch($action) {
            case 'append':
                $this->processAppend($productId);
                break;
            case 'reduce':
                $this->processReduce($productId);
                break;
            case 'clear':
                $this->processClear($productId);
                break;
            default:
                throw new ActionException($action, $this->session, $productId);
        }
    }

    private function processAppend($productId)
    {
        // ...
    }
    // ...
}

Это абсолютно не рашсряемо. Если у вам нужно подменить логгер в зависимости от окружения. Задача, кстати, очень частая, когда подменяют именно логер.

Card::change - вы жестко завязались на метод change который что-то делает.

Проблема целостности логики приложения — тут не видно ни связи текущего пользователя с корзиной. Потенциальная уязвимость того, что вы можете привязать товар ни к той корзине. Если один экшен, это не так критично. А представьте, если таких мест десятки. Как пример амазон. Там различных способов работы с корзиной кучи.

Проблема расширяемости. Вы не можете подменить спокойно реализацию корзины для разных пользователей. Например, если у юриков и у физиков разные способы размещения заказов в ней (если правильно помню, тоже из амзмона пример)

Вы, скажете, что это не проблема Laravel. А я скажу, что именно его. Потому что он не предоставляет своей методики, как правильно получать экземпляры, кроме как через запрос в контроллере через статические методы подключения к БД.

Далее. Как вы собираетесь прикручивать ко всему этому гибкие права. Например, у пользователя с ролью менеджера есть права только на чтение.

class CartChange extends FormRequest
{
    // НАПРИМЕР, ОДНА ИЗ ТОЧЕК ПРОВЕРКИ ПРАВ!!!
    public function authorize()
    {
        return true; // Если в данном контексте мы этим не замарачиваемся
    }

Теперь возвращаемся к коду. В CartChange много чего завязано на какие то ассоциативные массивы и куча публичных методов. Я не понимаю как это работает. Это вообще процедурное программирование. Тут нет реализации каких то интерфейсов, для понимания, что можно передать, а чего нельзя.

Это сплошное нарушение SOLID, так как CartChange нарушает принцип единой ответственности. Он предоставляет различные данные разной с разной природой.

Даже передавать разный request для каждого action попахивает. Меняем строчку в роутинге и вам приходит другой объект. Потенциальное место огрести кучу неявных ошибок.

<!-- Вариант с параметрами в URL -->
<form action={{ route('cart.change', ['action' => 'append', 'product' => $produt->id]) }} method="post">
    {{ csrf_field() }}
    <button type="submit">+</button>
</form>
<span>{{ $cart->productQuantity($produt->id) }}</span>
<form action={{ route('cart.change', ['action' => 'reduce', 'product' => $produt->id]) }} method="post">
    {{ csrf_field() }}
    <button type="submit">-</button>
</form>

<!-- Вариант с CartChange Параметры в форме  -->

<form action={{ route('cart.change') }} method="post">
    {{ csrf_field() }}
    <input type="hidden" name="action" value="append"> 
    <input type="hidden" name="product" value="{{ $produt->id }}"> 
    <button type="submit">+</button>
</form>
<span>{{ $cart->productQuantity($produt->id) }}</span>
<form action={{ route('cart.change']) }} method="post">
    {{ csrf_field() }}
    <input type="hidden" name="action" value="reduce"> 
    <input type="hidden" name="product" value="{{ $produt->id }}"> 
    <button type="submit">-</button>
</form>

Ниже я изменил реализацию с учётом ваших желаний. Простая реализация с привязкой к сессии. Кроме того добавил немного кода модели.

$cart = Cart::bySession($session_id)
                ->firstOrCreate(['session' => $session_id]);

Бизнесу нужны быстрые решения. Для этого нужно искать золотую середину, а не быть снобом.

По существу моего вопроса вы не ответили.