плохо

избавься от них)

ну то есть.... какого рода там if-ы?

(вообще очень сложно обсуждать задачу не зная задачи))

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

https://www.destroyallsoftware.com/talks/boundaries

вот к слову оч хороший доклад на эту примерно тему

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

окей... если нет ни одного наверное надо кинуть исключение?

p.s. если усложнять можно стратегию навернуть

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

точнее вынести ее можно и разделить

да, да, все правильно

правильно по поводу исключения?

правильно по поводу исключения?

по поводу стратегий

аа

избавься от них)

долго вспоминал про стратегию, в голове вертелось про OCP

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

долго вспоминал про стратегию, в голове вертелось про OCP

одно из самых эффективных средств в борьбе с if-ми

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

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

ну как... у тебя тест основного класса будет весьма и весьма нетривиальным

моки в перемешку с проверкой логики

ну то есть терпимо и если тебе норм то ладно

в целом в мое личное правило "не более двух моков на тест" пока оно вписывается)

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

в целом в мое личное правило "не более двух моков на тест" пока оно вписывается)

в данном случае моки = test doubles любого вида?

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

я стараюсь делать либо штуки в которых не нужны моки либо штуки где только моки (а такие вещи юнит тестами не покрываются)

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

в данном случае моки = test doubles любого вида?

в целом да

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

это всегда полезно)

в целом в мое личное правило "не более двух моков на тест" пока оно вписывается)

Что значит на тест?

Что значит на тест?

на тест кейс.

один конкретный тест кейс

Если объект требует инъекта 3 штук, то?

Если объект требует инъекта 3 штук, то?

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

и как только заканчиваю с этим удаляю тест

А, вот ты про что

Понял

про это было, кстати, в object calisthetics

типа "рекомендуется не более двух зависимостей"

типа "рекомендуется не более двух зависимостей"

серьезно?)) я везде про три находил)

погляжу посмотрю

ща попробую найти

http://williamdurand.fr/2013/06/03/object-calisthenics/

ты про это?

https://github.com/TheLadders/object-calisthenics

да, это оч крутая штука

я своим тоже даю обычно почитать

ну да

есть на русском

https://habrahabr.ru/post/206802/

А, прикольно да)

но я часто нарушаю этот принцип про "не более двух зависимостей"

точнее "не более двух атрибутов"

у меня есть сущости в которых по 20 атрибутов

в целом... там столько не надо и я сейчас это понимаю... но уже поздно)

оно работает, даже в целом не сказать что боль

планирую 5 полей вынести в другой объект но....

в целом да, если я заверну там все вещи в отдельные объекты у меня всеравно останется где-то 6 атрибутов и код в целом станет намного чище

но лень

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

Доктрина наверное это добро и сгенерила))

я просто тоже думал над этим, но не дошло до дела, т.к. издалека задумался о доктрине и забил

А в случае с vo, она ж вроде до сих пор страдает с nullable

я уже писал в тот чатик - энтити ORMки != доменная модель

Нуу

ERROR: S client not available

это ведь так?)

Обычно нет смысла

В таком делении

Т.е. если у тебя реально доктрина ограничитель, то ок

Можешь отдельно мапить

ну у моей модели нет id, к примеру

т.к. это поле относится к ORM

ну у моей модели нет id, к примеру

На такие уступки можно пойти, ведь сущность должна иметь уникальное поле

А поскольку мы объект восстанавливаем, то ссылки языка как уникальность юзать не выйдет

Плюс в разных аггрегатах лучше держать не прямые ссылки, а именно id

Правило: за одну транзакцию меняем один аггрегат

а если возникла необходимость переехать с DataMapper на ActiveRecord, например?

а если возникла необходимость переехать с DataMapper на ActiveRecord, например?

Ну тогда ar - это dao

А сущность продолжает ничего не знать)

Вообще под id если упарываться надо пилить отдельный класс под аггрегат, который заворачивает uuid

а если возникла необходимость переехать с DataMapper на ActiveRecord, например?

Но кейс очень прямо нереальный)

я рассуждаю просто в рамках того, возможно ли отделить доменную логику от ORM

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

Дата маппер и предполагает разделение, ты типа вначале сделал свой домен, а потом поставил доктрину/гибернейт, вжух и все персистентно

я уже писал в тот чатик - энтити ORMки != доменная модель

если ORM != доменная модель то тогда не надо юзать доктрину. Но если ты готов мириться с ограничениями вроде nullable embeddable (делать null objects лучше всеравно) то как бы проблем с этим нет и реализация сильно проще.

ну то есть все сильно зависит от реализации

использовать доктрину тупо как DTO между базой и моделью чет как-то меня не радует. Лучше буду dao юзать на каком-нибудь крутом квери билдере

использовать доктрину тупо как DTO между базой и моделью чет как-то меня не радует. Лучше буду dao юзать на каком-нибудь крутом квери билдере

Да разница небольшая

я все понял, спасибо

Да разница небольшая

?

?

Ну какая разница потом в дао все прокинуть или в dto?

Ну какая разница потом в дао все прокинуть или в dto?

эм.... я в dao буду гидрировать свои сущности)

ну то есть та же доктрина просто кастомные гидраторы)

и намного проще

возможно с unit-of-work-ами

(не одним универсальным а специализированными под агрегаты)

каждому агрегату свой юнит ов форк