Разработка это во многом бизнес вопросы

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

просто будь готов изменять код постоянно

Разработка это во многом бизнес вопросы

bullshit

Как делать сейчас очень сильно зависит от нужд бизнеса

Иначе зачем вообще делать, если мы кладем болт на их нужды :)

Вопрос дальше в сложности кода и приложения, процедурный скрипт на 100 строк или объектная модель

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

Как делать сейчас очень сильно зависит от нужд бизнеса

Бывает и так, что бизнес сам не до конца определился ☺️

Иначе зачем вообще делать, если мы кладем болт на их нужды :)

ты себе противоречишь

Бывает и так, что бизнес сам не до конца определился ☺️

Не бывает иначе)

ты себе противоречишь

Конкретнее

Сайт FBI был взломан видели?

exploit 0day

от cms

пиздец

Если нужна модель уровня школьной, то тоже ещё вопрос нужно ли

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

Сайт FBI был взломан видели?

Скажут, что Путин лично взломал))))

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

Точно простой?

Да эти дебилы надоели с обвинениями ))

http://thehackernews.com/2017/01/fbi-plone-cms-hacked.html

да модель может быть простой, как и бизнес

да модель может быть простой, как и бизнес

Можно пример точнее?

лендинг например, одно поле для ввода email

А домен где?)

Это представление, давай про предметную область

https://dev.by/lenta/main/nashi-na-PH

внезапно

@ludichello

лендинг например, одно поле для ввода email

лэндинг это тупо статическая страничка, о какой предметной области мы тут говорим? Твой пример с полем email это чисто view layer

да. уже отмечаем :)

Раз уж вы коснулись этой темы, пожалуйста, апните нас на продуктханте

Раз уж вы коснулись этой темы, пожалуйста, апните нас на продуктханте

Кинь линк

https://www.producthunt.com На заглавной сейчас Eightydays.me

А домен где?)

не догадался сам?! печалька. домен в сохранении email'а пользователя

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

не догадался сам?! печалька. домен в сохранении email'а пользователя

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

ну че за https://github.com/reactphp/http/pull/82

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

ахаха

а у кого-нибудь есть ссылка, где на пхп запилили для суммы какую-то дикую объектную модель поприколу

я ее видел на хабре давно, может в 2012

не догадался сам?! печалька. домен в сохранении email'а пользователя

домен на уровне CRUD?

смешно немного

инварианты на уровне "email должен быть email-ом"

вот если бы ты начал про рассылки таргетированные

там уже можно говорить о каких-то "доменах"

домен на уровне CRUD?

на уровне C

RUD нету )

и то верно

воооо https://github.com/Herzult/SimplePHPEasyPlus

воооо https://github.com/Herzult/SimplePHPEasyPlus

echo 1+1; и нинужно

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

ну вот этом ж прикол

да был бы прикол...

э, ну это вот прикол)

каждая вторая либа делает то же самое...

вот и не ясно - нахера? ну, пусть не каждая вторая, путь и в ноде не везде юзаются is-true и is-false... но нахера засерать этим говном то, что и так по уши в дерьме...

вот если бы ты начал про рассылки таргетированные

вот и мне смешно! вы в контексте кода только смотрите на проблему. просто нужно позадавать вопросы "что такое email", там может появится "клиент", "потенциальный клиент" и тд и тп. да выглядит как over engineering с одной стороны - но по факту эванса читали все с середины второй главы.

вот и мне смешно! вы в контексте кода только смотрите на проблему. просто нужно позадавать вопросы "что такое email", там может появится "клиент", "потенциальный клиент" и тд и тп. да выглядит как over engineering с одной стороны - но по факту эванса читали все с середины второй главы.

Окей, зачем ты пишешь код?

Даже скорее зачем кому-то нужен ты, который будет писать код

решать бизнес-задачи

зачастую

Окей, зачем ты пишешь код?

окей гугл, зачем писать код?! лучше расскажи кому нужен ТЫ, начни с себя. аргументированный разговор закончился ещё пару сообщений назад

тут явно не хватает дружко (с)

решать бизнес-задачи

Я вот этим занимаюсь

Я вот этим занимаюсь

а бывает по другому если не опенсорс и не грантоед?:)

а бывает по другому если не опенсорс и не грантоед?:)

Вот человек вроде как-то иначе считает

ERROR: S client not available

вот и мне смешно! вы в контексте кода только смотрите на проблему. просто нужно позадавать вопросы "что такое email", там может появится "клиент", "потенциальный клиент" и тд и тп. да выглядит как over engineering с одной стороны - но по факту эванса читали все с середины второй главы.

не ну все так примерно и делают.

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

а бывают более сложные штуки

но эти сложные штуки как правило работают не тупо с email-ами

а анализируют кучу других вещей

Окей, зачем ты пишешь код?

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

а бывает по другому если не опенсорс и не грантоед?:)

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

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

просто там нет "объектов" в привычном смысле

как пример....

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

как поступили разработчики.... у нас есть 40 форм, мы сделаем вам 40 форм....

лэйблы захардкожены на клиенте, правила валидации на сервере...

если вдруг добавится 41-ая или еще веселее - если надо будет добавить еще одно поле в 10 форм

то придется задействовать ажно 2 человека что бы все поправить

почему разработчики сделали так - они мотивировали это тем что не хотели усложнять реализацию, мол никаких требований в плане "менять потом" небыло. Мол изменения если и будут - они будут раз в пол года. Нечего автоматизировать такое. И в целом они правы... вот только их реализация настолько примитивна, что потрать они на неделю больше времени на костяк то эти трудозатраты окупились бы уже после добавления 20-ой формы.

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

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

чет меня понесло... ладно

я напомню что я начал про это, @fes0r похоже понял про что я ;)

вот не согласен, DDD это про формирование модели, единый язык и перевращение всего этого в код с помощь удачных приемов конкретного автора все упарываются только по технической части DDD

> все упарываются только по технической части DDD тут согласен)

хотя не совсем... не все...

но большинство

для многих DDD это репозитории, сущности и все такое

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

куда запихнуть проверку данного правила?

например есть у нас метод changeUsername(string $username): void

сущность юзера ничего не знает о других юзернеймах

и проверить это не может

а потому можно прибегнуть к метафорам... например мы просим реального юзера поменять юзернейм. Как он будет соблюдать это бизнес правило? Наверное мы дадим ему какой-то способ узнать является ли выбранный юзернейм уникальным

changeUsername(string $username, UsernameUniquness $checker): void