Как отделить бизнес-логику?

3 вопроса
  1. Как уйти от толстых моделей? У меня, к примеру, модель User может быть на тысячу строк. Говорят, нужен сервисный слой. Но я не пойму как его организовать на уровне файлов и папок и как это должно примерно выглядеть. Может быть есть примеры кода?
  2. Допустим, я хочу внедрить на сайт сервис PayPal (общается по curl'у c их сервером). В Yii, например, я создавал файл-класс PayPal в папке components и там реализовывал методы. Добавлял в конфиг и потом использовал как Yii::$app->paypal в контроллере и в модели (опять же - бизнес-логика в контроллере и модели). Довольно примитивно. Как мне грамотно создать такой модуль в Laravel. В какой папке? Нужно ли разделать на контракт/реализацию, если реализация всего одна? (опустим, что можно создать единый контракт для всех платёжных систем)
  3. Почему в laravel нет папки Model и модели складываются в App. Знаю, что можно создать самому? Но зачем это сделано. Папка Model — устаревшая структура и есть способ организовать модели по-лучше?
  • Вопрос задан
  • 4178 просмотров
Решения вопроса 2
@Majesko
1. Создать папку Services
2. Выделить части бизнес логики в сервисы
3. Написать сервисы и подключить через Service Provider в Service Container
4. Написать фасады (по желанию)
5. ...
6. PROFIT
Ответ написан
@springimport
Раз на вопросы уже ответили, пишу свои рекомендации:
1. Yii < Laravel < Symfony. Вы можете делать архитектуру как "принято" в фреймворке или по ddd.
2. Легкие и средние проекты не обязывают к ddd, сложные - требуют.

Компоненты и paypal. Я всегда стараюсь вынести общий код в отдельную либу или в отдельный класс которые уже можно использовать в /components.

Сервисы. Обычно нужны в ddd, но и в обычном проекте тоже можно использовать. Просто не так удобно. Например, yii создает rest api напрямую с моделями.
Ответ написан
Пригласить эксперта
Ответы на вопрос 9
dmitriylanets
@dmitriylanets
веб-разработчик
1. я бы реализовал работу с PayPal в виде фраймворко независимой библиотеки (хотябы минимум зависимостей) для начала в src/paypal после реализации подключил бы через composer
2. Уровень сервиса это не работа с PayPal конкретно а работа с платежной системой, то есть Paypal бы шел как драйвер
use App\Services;

class Payment {

	protected $payment;

	public function __construct(\App\Contracts\PaymentDriverInterface $payment) {
		$this->payment = $payment;
	}

	public function createPaymentUrl() {
		return $this->payment->getUrl();
	}

}

namespace PayPal;

class PayPalDriver implements \App\Contracts\PaymentDriverInterface {

	public function getUrl() {
		//реализация
	}

}
Ответ написан
@Kostik_1993
Fullstack Web Developer | PHP | Laravel | Vue.js
Мне кажется ты слишком заморачиваешься. Во первых, точно ли то что у тебя в моделях является бизнес логикой? Если да то создаем папку Services и в ней у тебя могут располагаться некие классы для обработки чего либо допустим класс для отвязки или привязки аккаунта к соц.сети
class UserSocialServices
{
    public function createOrGetUser() {}
    public function associate() {}
}
// или можно
class PayPall {
    public function createPaymentUrl() {}
}


Что касаемо не бизнес логики, а я думаю что там у вас 50 на 50, то ее можно вынести в трейты, особенно те, что могут дублироваться в разных моделях. Вообще четкого разделения на папки нет, это ваш проект, главное чтоб папки назывались понятно, а их содержимое им не противоречило
Ответ написан
solotony
@solotony
покоряю пик Балмера
1) бизнес-логика на 10000 строк - я бы переживал. долго листать. а 1000....
мне тут один заказчик высказал что у мня "файлы большие" - я ему - " вносим изменения в ТЗ и делаем переоценку ?" он вроде успокоился.

2) пейпал не разу ни бизнес логика

3) вопрос задай Тейлору. он отвечает.
Ответ написан
Ни Yii, ни Laravel не следуют DDD. Не заморачивайтесь. Делайте или в рамках фреймвока, или если знаете DDD, то в рамках него. Только вас погонят "лопатой по спине".

Сейчас в издательстве Питер вышла жёлтая книжка с пчёлкой. Она хорошая. Это не реклама. Достаточно придерживаться её.
Ответ написан
@spaceatmoon
https://p1d1.blogspot.com
1. Вообще вопрос из разряда "Критикуя предлагай". Кто говорит, что говорит это уже третье. Если сами чувствуете, что модель можно проредить, что-то выкинуть в класс API для этой модели, то делайте.
2. В интеграции PayPal нет бизне-логики, это глупости. Но вот методы запросов можно хранить в одном классе, а конфигурации в другом, использования данных в третьих.
3. Почему нет папки? Потому что. Это не значит что нужно слепо следовать какой либо парадигме, это просто кто-то когда так придумал.

Вы должны сами почувствовать где что должно лежать и как. У меня средний класс занимает до 500 строк.
Ответ написан
Sassoft
@Sassoft
Yii developer
Внедрите что-то типа командной шины и складывайте конкретно команды и обработчики
Ответ написан
gaparchi
@gaparchi
Правильно fpinger пишет. DDD призвано решать эти вопросы. Но придется вдумчиво книжечки почитать.
Ответ написан
customtema
@customtema
arint.ru
Я сделал это.

Правда, думал, что управлюсь за пару месяцев, а заняло пару лет: nextframework.ru
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы