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

Question

[l4m3r]

3 вопроса

1. Как уйти от толстых моделей? У меня, к примеру, модель User может быть на тысячу строк. Говорят, нужен сервисный слой. Но я не пойму как его организовать на уровне файлов и папок и как это должно примерно выглядеть. Может быть есть примеры кода?
   
2. Допустим, я хочу внедрить на сайт сервис PayPal (общается по curl'у c их сервером). В Yii, например, я создавал файл-класс PayPal в папке components и там реализовывал методы. Добавлял в конфиг и потом использовал как Yii::$app->paypal в контроллере и в модели (опять же - бизнес-логика в контроллере и модели). Довольно примитивно. Как мне грамотно создать такой модуль в Laravel. В какой папке? Нужно ли разделать на контракт/реализацию, если реализация всего одна? (опустим, что можно создать единый контракт для всех платёжных систем)
   
3. Почему в laravel нет папки Model и модели складываются в App. Знаю, что можно создать самому? Но зачем это сделано. Папка Model — устаревшая структура и есть способ организовать модели по-лучше?
   

Comments

[Sergej]

Почитайте о DDD.
Некоторые реализации для Laravel можно посмотреть на гитхабе

[JhaoDa]

Вам бы для начала с композером разобраться, про PSR-4 почитать...

[l4m3r]

SharkMan, посмотрю. Читал, но как-то все абстрактно. Может у вас есть хорошая статья с примерами?

[l4m3r]

JhaoDa, лол. Причем тут композер вообще и почему вы думаете, что я в нем не разбираюсь?

[JhaoDa]

l4m3r, я так думаю из-за вопроса №3.

[l4m3r]

JhaoDa, перечитал свой вопрос, так и не понял причём тут композер)

[JhaoDa]

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

[l4m3r]

JhaoDa, вопрос был: ПОЧЕМУ папки Models нет в стандартной поставке лары, как у других фреймворках. Контроллеры и провайдеры же отделили в отдельные папки, хотя их тоже можно по-разному организовать, а вот для моделей нет —организовывай как хочешь.

[spaceatmoon]

SharkMan, для рядового приложения DDD избыточно.

[xfg]

spaceatmoon, у человека 1к строк на класс, ваши предложения?

[spaceatmoon]

xfg, без примера кода я не могу ничего посоветовать. Если это его так напрягает, то пусть сделает анализ кода и отделит "тупые" куски в отдельные классы.

[Sergej]

spaceatmoon, Я не говорю о полной его реализации, в конкретном случае важен сам принцип построения.

[xfg]

spaceatmoon, вы и с примером кода ничего толкового не посоветуете. Это будет локально. Вырвано. Не систематизировано. Бесполезно. Невозможно спроектировать систему не имея навыков проектирования. Сколько не анализируй код. Многие не понимают, где бизнес код, где инфраструктурный, как это делить и почему. Многие на PHP пишут интуитивно. Результатом такой деятельности является спагетти-код. В книге Implementing domain-driven design есть решение по проектированию от начала и до конечного результата.

[spaceatmoon]

xfg, плюсую ваш ответ.

Answer 1

[Majesko]

1. Создать папку Services
2. Выделить части бизнес логики в сервисы
3. Написать сервисы и подключить через Service Provider в Service Container
4. Написать фасады (по желанию)
5. ...
6. PROFIT

Comments

[Barmunk]

Я тоже к этому пришел, отлично позволяет наследоваться

->middleware
->formRequest
->controller
->serviceClass

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

Answer 2

[Михаил]

Раз на вопросы уже ответили, пишу свои рекомендации:
1. Yii < Laravel < Symfony. Вы можете делать архитектуру как "принято" в фреймворке или по ddd.
2. Легкие и средние проекты не обязывают к ddd, сложные - требуют.

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

Сервисы. Обычно нужны в ddd, но и в обычном проекте тоже можно использовать. Просто не так удобно. Например, yii создает rest api напрямую с моделями.

Answer 3

[dmitriy]

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() {
		//реализация
	}

}

Answer 4

[Евгений Педя]

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

Сейчас в издательстве Питер вышла жёлтая книжка с пчёлкой. Она хорошая. Это не реклама. Достаточно придерживаться её.

Comments

[gaparchi]

А как книжечка называется?

[Евгений Педя]

Роберт Мартин - Чистая архитектура. Искусство разработки программного обеспечения.
Она не о DDD, но без неё DDD изучать трудно.
По DDD на русском выходили три основные книги:
Эванс - Предметно-ориентированное проектирование (Eric Evans - Domain-Driven Design)
Вернон - Реализация методов предметно-ориентированного проектирования (Vaughn Vernon - Implementing Domain-Driven Design)
Вернон - Предметно-ориентированное проектирование (Vaughn Vernon - Domain-Driven Design Distilled)
В электронном виде на русском проблемы с их получением. Первую можно ещё найти в качестве пиратки. Остальные две есть только на складчинах. А в бумаге на периферии книги в будут дорогими. И мне трудно прокомментировать перевод.

Так же есть ещё две книги со спецификой на языки:

Jimmy Nilsson - Applying Domain-Driven Design and Patterns: With Examples in C# and .NET (есть перевод и можно в электронном виде пиратку найти).

Scott Millett, Nick Tune - Patterns, Principles, and Practices of Domain-Driven Design (есть перевод, но получить только через склатчины в электронном виде)

Carlos Buenosvinos, Christian Soronellas, Keyvan Akbary - Domain-Driven Design in PHP (перевода не видел, изначально публиковалась на Leanpub, но потом переехала на Packt Publishing)

Все книги можно найти на английском в электронном виде. Пиратки. Или купить. Из-за кучи терминов книги по DDD читаются трудно и медленно. Понимаются так же. :)

[dmitriy]

fpinger спасибо за книгу

Answer 5

[Константин Б.]

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

class UserSocialServices
{
    public function createOrGetUser() {}
    public function associate() {}
}
// или можно
class PayPall {
    public function createPaymentUrl() {}
}

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

Answer 6

[Antonio Solo]

1) бизнес-логика на 10000 строк - я бы переживал. долго листать. а 1000....
мне тут один заказчик высказал что у мня "файлы большие" - я ему - " вносим изменения в ТЗ и делаем переоценку ?" он вроде успокоился.

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

3) вопрос задай Тейлору. он отвечает.

Answer 7

[ALIAKSANDR ZHALIAZOUSKI]

В zf2 отлично видно как работают сервисы

Answer 8

[spaceatmoon]

1. Вообще вопрос из разряда "Критикуя предлагай". Кто говорит, что говорит это уже третье. Если сами чувствуете, что модель можно проредить, что-то выкинуть в класс API для этой модели, то делайте.
2. В интеграции PayPal нет бизне-логики, это глупости. Но вот методы запросов можно хранить в одном классе, а конфигурации в другом, использования данных в третьих.
3. Почему нет папки? Потому что. Это не значит что нужно слепо следовать какой либо парадигме, это просто кто-то когда так придумал.

Вы должны сами почувствовать где что должно лежать и как. У меня средний класс занимает до 500 строк.

Answer 9

[Alexander]

Внедрите что-то типа командной шины и складывайте конкретно команды и обработчики

Answer 10

[gaparchi]

Правильно fpinger пишет. DDD призвано решать эти вопросы. Но придется вдумчиво книжечки почитать.

Answer 11

[Артем Спиридонов]

Я сделал это.

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