например модель заказа тебе надо посчитать сумму товаров в нем

Одни читатели нас хотят читать, мать их, вторые не могут и в фб жалобы пишут

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

я про бизнес логику

http://ocramius.github.io/doctrine-best-practices/#/37 определимся с терминами то, что на слайде пойдет за бизнес-логику?

с rich model это класс модели у которого состояния - пропсы и методы для их изменения

например модель заказа тебе надо посчитать сумму товаров в нем

$order->getSum() - ?

нет?

товары в заказе это другие сущности

public function getSum() { $sum = 0; foreach ($this->products as $product) { ... } return $sum; }

товары в заказе это другие сущности

это называется агрегат

ну и как бы в твоем домене ордер содержит в себе ссылки на продукты

ну и у этих продуктов есть логика которую ты должен использовать

метод getPrice()

это не логика это геттер)

Еще один дилетантский вопрос: странно ли было бы назвать репозиторий отлично от названия сущности? Хочу сделать так: сущность MapPoint и репозиторий GeographicalCoverageRepository.

это не логика это геттер)

Внутри него и содержится логика относительно того, как считать сумму товаров. Может, там будет скидка?

или купон активированный

или купон активированный

и это уже не геттер

а что? сервис?

Активированный купон звучит как часть заказа. Поэтому он и пойдет в заказ и будет использоваться в методе getSum().

и назвать его можно не getPrice, а calculatePrice, например)

ну находу я хороший пример не придумал да) то есть сервисы с бизнес логикой нам впринципе не нужны и их никто не делает?)

все в классе с сущностью доктрины верно?

все в классе с сущностью доктрины верно?

да

Поведение, которое принадлежит сущности, в классе с сущностью доктрины Поведение, которое вне сущности, лежит в отдельном сервисе

Еще один дилетантский вопрос: странно ли было бы назвать репозиторий отлично от названия сущности? Хочу сделать так: сущность MapPoint и репозиторий GeographicalCoverageRepository.

вполне ок

> то есть сервисы с бизнес логикой нам впринципе не нужны и их никто не делает?) обычно сервисы описывают какой-то процесс, когда сложно отнести что-то к отдельной сущности и то это довольно таки не частый кейс

у сущностей отдельный цикл жизни от цикла жизни контейнера. ты не сможешь никак в сущности пихать референсы на какие-либо сервисы, репосы и прочий булшит, только дабл диспатч в редких случаях а rich model не стоит путать с AR

так, другой пример) пополнить баланс пользователя = назначить ему свойство + создать транзакцию пополнения это модель пользователя?

ты всегда можешь аргументом в метод сущности кинуть сервис, через который сущность сделает все, что ей нужно

а у этого сервиса своя зависимость

User->deposit(100)

это уже никого не волнует

> создать транзакцию пополнения транзакция это уже инфраструктура

а у этого сервиса своя зависимость

с этим современные пыховские контейнеры отлично справляются)

проблема в том что в реальной жизни деньги материальны

те у тебя есть материальный эквивалент ценности

User->deposit(100)

не, ну Money::USD(100 * 100) хотя бы ))

и если на сделку смотреть не с точки зрения комп системы, там нет транзакций

а если он скажет что деньги не пришли?)

а ты ему их перевел через банк) транзакция не нужна?

> создать транзакцию пополнения транзакция это уже инфраструктура

я так понял он имел в виду транзакцию в смысле запись в таблице

и если на сделку смотреть не с точки зрения комп системы, там нет транзакций

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

а ты ему их перевел через банк) транзакция не нужна?

Как-то анемичная модель этому поможет? Как-то rich model как этому помешает?

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

да почему, ты по договору должен перевести на счет

подтверждение этому транзакция

в банках есть) транзакция это снятие с одного счета и зачисление на другой счет, это 2 операции

и эта бизнес задача - одна модель, но она рассеивается на несколько классов

и эта бизнес задача - одна модель, но она рассеивается на несколько классов

твоя модель может состоять из множества сущностей, агрегатов и тп

конечно, но все что требует зависимостей которые тоже имеют зависимости будет в сервисе

и останутся сеттеры/геттеры в энтити

в банках есть) транзакция это снятие с одного счета и зачисление на другой счет, это 2 операции

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

и останутся сеттеры/геттеры в энтити

нет

1. доменные ивенты 2. double dispatch

и готово

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

double entry bookkeeping же

double entry bookkeeping же

че?

а, понял

конечно, но все что требует зависимостей которые тоже имеют зависимости будет в сервисе

слишком однобокий взгляд на вещи. Попробуй смотреть на проблему через призму "информационного эксперта" и "information hiding"

и пока не попробуешь и не появятся конкретные вопросы - считаю разговор пустышкой

я могу сказать что без сеттеров уж точно можно делать, и даже без геттеров (но тут есть нюансы)

суть в том что в сервисах у тебя в принципе не должно быть кода в духе $transaction = new Transaction(); $transaction->setAmout(...); $transaction->setCreatedAt(..); $user->getTransactions()->add($transaction); $user->setBalance(...) $em->persist($transaction);

это называется transactional scripts

Sergey а что должно быть?)

$this->userManager->addBalance() ?)

ERROR: S client not available

$transaction = new Transaction($user, $amount); $em->persist($transaction);

а еще лучше persist спрятать в репозитории

Sergey а что должно быть?)

$user->deposit(...)

тоже норм

только $account

$user->transfer($amount, $anotherUser)

хотя от домена зевисит

только $account

user чтобы понятнее было

а то доебутся еще до названия

bounded context же))

можно еще даже так $transaction = $user->transfer($amount, $anotherUser);

но это уже it depends

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

$user->transfer($amount, $anotherUser) а если $amount это объект из суммы, валюты, etc, мы его предварительно формируем в сервисе ?

слишком однобокий взгляд на вещи. Попробуй смотреть на проблему через призму "информационного эксперта" и "information hiding"

почитаю спасибо

мне кажется что проблема кучи сервисов и того примера с setter-ми что выше происходит из-за манипуляции не объектами а данными - типа как их распихать по разным структурам

$user->transfer($amount, $anotherUser) а если $amount это объект из суммы, валюты, etc, мы его предварительно формируем в сервисе ?

не обязательно, он может формироваться в месте вызова $user->transfer($amount, $anotherUser) или отдаваться фабрикой

например ты юзеров же как-то достал

ну и с $amount также

$user->transfer($amount, $anotherUser) а если $amount это объект из суммы, валюты, etc, мы его предварительно формируем в сервисе ?

да, это будут своего рода реализации юзкейсов

можно еще отдельные бизнес правила и т.д. выносит в сервисы

но это уже будут не доменные сервисы

больше заточенные под приложение, чисто для оркестрации изменения состояния системы

но это уже будут не доменные сервисы

можно и доменные

там много чего можно делать

главное не зацикливаться на идее "есть сервисы и сущности"

Вы используете inline стили?

Вы используете inline стили?

CSS?

ага

inline styles юзаем для отрисовки critical path css

Что это?

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