С какой целью разрабатывается фреймворк

Не относящиеся к фреймворку и программированию вопросы
Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение BrusSENS » 2019.05.02, 23:59

maleks писал(а):
2019.05.01, 14:50
Книги то по архитектуре, DDD, идут без привязки к ЯП.
КЭП детектед. Почитайте, насколько стара парадигма DDD.
maleks писал(а):
2019.05.01, 14:50
а у нас тут про проблемы таких AR архитектур до сих пор многие не догадываются
AR архитектур... Вы реально почитайте сначала то, что Вы пишите, прежде чем сей вброс публиковать. AR - паттерн проектирования, но никак не архитектура. Покажите мне реальный проект, которому нужен DDD? Правильно, не покажете, ибо таких проектов один на миллион, и то я сомневаюсь в рациональности данного подхода.
Знаете, замечаю прикольные штуки в последнее время с проектами... DDD стало модным, а проекты берёшь и диву даёшься. Блоги пытаются писать FA...
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
ElisDN
Сообщения: 5411
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN » 2019.05.03, 01:13

BrusSENS писал(а):
2019.05.02, 23:59
Покажите мне реальный проект, которому нужен DDD? Правильно, не покажете, ибо таких проектов один на миллион...
У меня практически каждый, который сложнее просто блога: залоговый аукцион, биржа автосервисов, бронирование билетов, кабинет ученика, менеджер проектов, платные ресурсы. Всё с блэкджеком и тестами.
BrusSENS писал(а):
2019.05.02, 23:59
...и то я сомневаюсь в рациональности данного подхода.
DDD – это изначально не про программирование, а про идею UL и BC. А в технической реализации естественно получается из них канонический ООП. Ваш кэп.
Последний раз редактировалось ElisDN 2019.05.03, 01:16, всего редактировалось 1 раз.

anton_z
Сообщения: 439
Зарегистрирован: 2017.01.15, 15:01

Re: С какой целью разрабатывается фреймворк

Сообщение anton_z » 2019.05.03, 01:15

ElisDN писал(а):
2019.05.03, 01:13
У меня практически каждый, который сложнее просто блога: залоговый аукцион, биржа автосервисов, бронирование билетов, кабинет ученика, менеджер проектов, платные ресурсы.
А разработчиков сколько? Вы один? И при этом у вас DDD?

ElisDN писал(а):
2019.05.03, 01:13
А в технической реализации естественно получается из них канонический ООП.
Не верю в "естественно". Ничем это не доказано, и что такое "канонический ООП" вовсе непонятно. ООП до DDD несколько десятилетий существовало.

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение BrusSENS » 2019.05.03, 01:56

ElisDN писал(а):
2019.05.03, 01:13
У меня практически каждый, который сложнее просто блога: залоговый аукцион, биржа автосервисов, бронирование билетов, кабинет ученика, менеджер проектов, платные ресурсы. Всё с блэкджеком и тестами.
Какой Вы молодец. Это же хорошо, что всё так прекрасно. Но. Я так и не увидел никакого профита от использования всего этого добра, называемого DDD. Тесты писать можно для чего угодно. Не всегда тесты - залог правильной работы приложения. Смотря кто их пишет. Блэкджек - тоже для каждого свой.
ElisDN писал(а):
2019.05.03, 01:13
DDD – это изначально не про программирование, а про идею UL и BC. А в технической реализации естественно получается из них канонический ООП. Ваш кэп.
Канонический ООП - это когда абстракция используется для того, что бы решить определённые проблемы. DDD с его паттернизмом - неоправданное усложнение кода и оверхед в 99% случаев. Ваш кэп.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
ElisDN
Сообщения: 5411
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN » 2019.05.03, 02:52

anton_z писал(а):
2019.05.03, 01:15
А разработчиков сколько? Вы один?
Бронирование авиабилетов целый год втроём пилили. Аукцион и автосервисы я один. Так что по-разному.
anton_z писал(а):
2019.05.03, 01:15
И при этом у вас DDD?
Да. Строку $order->status = CLOSED заменяем на $order->close() и внезапно получаем DDD. Это не так уж и сложно.
anton_z писал(а):
2019.05.03, 01:15
Не верю в ваше "естественно". Ничем это не доказано, и что такое "канонический ООП" вовсе непонятно. ООП до DDD несколько десятилетий существовало.
DDD говорит нам опираться на термины и процессы бизнеса. Выделять обособленные подсистемы и в них максимально работать с абстракциями вещей из реальной предметной области. Говоря проще, называть объекты и их методы реальными именами, которыми их называет заказчик. Вроде $склад->зарезервируй($товар->id, $количество).

А ООП придумывалось (почти) для абстрактного моделирования объектов и процессов их взаимодействия из реальной жизни и для модульности. То есть для того же самого. Но все эти десятки лет большинство программистов на своей волне так и пишет непонятный соседу и заказчику низкоуровневый процедурный лапшекод в контроллере, без разбора и абы как составляя и называя переменные и классы.

А DDD как методика всего лишь говорит выстроить процесс разработки так, чтобы заказчик говорил с разработчиком на одном языке. И чтобы в коде они могли использовать по назначению на полную мощность как раз тот самый ООП, проектируя и называя объекты и процессы по-человечески, а не по программистски.

Так что DDD – это не про паттерны.
Последний раз редактировалось ElisDN 2019.05.06, 15:15, всего редактировалось 2 раза.

anton_z
Сообщения: 439
Зарегистрирован: 2017.01.15, 15:01

Re: С какой целью разрабатывается фреймворк

Сообщение anton_z » 2019.05.03, 03:59

ElisDN писал(а):
2019.05.03, 02:52

Да. Строку $order->status = CLOSED заменяем на $order->close() и внезапно получаем DDD. Это не так уж и сложно.
Что ж вы лукавите? Если следовать вашему утверждению, то весь код, в котором вместо присваивания публичному свойству значения напрямую используется метод, становится кодом, написанным по DDD? :D


А как же Ubiqutios Language, карты контекстов, Domain Events и все остальное? Или вы все-таки не полностью DDD применяете?
ElisDN писал(а):
2019.05.03, 02:52
А ООП придумывалось для абстрактного моделирования объектов и процессов их взаимодействия из реальной жизни
Ну вот не согласен с этим я. Считаю, что это заблуждение. Нет ничего в определении ООПhttps://ru.wikipedia.org/wiki/Объектно- ... ммирование про реальную жизнь. Это лишь способ построения программы.

Аватара пользователя
maleks
Сообщения: 1764
Зарегистрирован: 2012.12.26, 12:56

Re: С какой целью разрабатывается фреймворк

Сообщение maleks » 2019.05.03, 07:50

BrusSENS писал(а):
2019.05.02, 23:59
maleks писал(а):
2019.05.01, 14:50
Книги то по архитектуре, DDD, идут без привязки к ЯП.
КЭП детектед. Почитайте, насколько стара парадигма DDD.
maleks писал(а):
2019.05.01, 14:50
а у нас тут про проблемы таких AR архитектур до сих пор многие не догадываются
AR архитектур... Вы реально почитайте сначала то, что Вы пишите, прежде чем сей вброс публиковать. AR - паттерн проектирования, но никак не архитектура.
Я спрашивал о чем интересном вы узнали, может наткнулись где то вне PHP на интересную инфу. Но вброс так вброс...

Насчет AR архитектур, ну мы ж тут не кандидатские защищаем, можно попытаться и суть сказанного, а не форму уловить.
Доменная модель - это сердце любой архитектуры и если она реализована на AR объектах, то как бы на многое влияет. Как пруф, много ли кто в Yii проектах, отказался от AR, я например не встречал. Причем последние - это даже не фаулеровские какие то AR, а свои, фреймворковские, с валидациями, функционалом для форм и т.д.

Аватара пользователя
ElisDN
Сообщения: 5411
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN » 2019.05.03, 11:26

anton_z писал(а):
2019.05.03, 03:59
Что ж вы лукавите? Если следовать вашему утверждению, то весь код, в котором вместо присваивания публичному свойству значения напрямую используется метод, становится кодом, написанным по DDD? :D
Да. Если в коде технические структуры с полями вроде присваивания и чтения $order->status заменить на полноценные объекты с понятными доменными методами $order->close() и $order->canBeDelivered() по UL нашей предметной области, то получим Object Oriented код с Domain Driven именованием. В чём лукавство?
anton_z писал(а):
2019.05.03, 03:59
А как же Ubiqutios Language, карты контекстов, Domain Events и все остальное? Или вы все-таки не полностью DDD применяете?
Вот по UL мы и называем наши модули, объекты и методы. А сложные системы при необходимости разбиваем на контексты, как это делается умышленно при разбиении на микросервисы или получается неумышленно само по себе:

При интеграции CRM, биллинга, рассылки, склада и 1С в любом бизнесе как раз и получается система, где CRM живёт с контекстом клиентов, МойСклад работает в контексте продаж в магазинах, 1С обслуживает это же с точки зрения бухучёта. И нам нужно организовать взаимодействие этих контекстов. Как? Через хуки по их Domain Events, чтобы при оформлении заказа в одном месте его данные попадали из события в наш обработчик-медиатор и им по API раскидывались во все остальные.

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

Если пишем с нуля крупную систему и не хотим упереться в сложность, то желательно делать аналогичное разбиение на слабосвязанные модули по смысловым контекстам. Это элементарный здравый смысл. А если пишем мелкий проект, который определяет один контекст и взаимодействовать не с кем, то и события никому не нужны.
anton_z писал(а):
2019.05.03, 03:59
Ну вот не согласен с этим я. Считаю, что это заблуждение. Нет ничего в определении ООП про реальную жизнь. Это лишь способ построения программы.
Да, это способ построения программы. Программы, которой моделируют какую-то часть реальной жизни. ООП - один из способов структурировать код модульно по ответственностям. Здесь:
абстрагирование для выделения в моделируемом предмете важного для решения конкретной задачи по предмету
и в других определениях обратите внимание на слово "моделирование". Все программы и программирование вообще используются для моделирования и формализации на компьютере чего-то из имеющихся вещей и процессов. Чтобы на нём решать практические жизненные задачи, а не чисто ради фана. А ООП вы возьмёте, ФП или процедурное - это уже какой стиль больше подойдёт. Для оперирования данными в математических задачах удобнее ФП, для моделирования объектов и взаимодействий удобнее ООП, для решения квадратного уравнения по действиям достаточно простыни императивного пошагового кода.

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

А если воспринимаете DDD как нечто техническое, заставляющее Вас использовать все паттерны, то значит прочли книгу не с той стороны. Как детей в книгах интересуют только картинки, так и программистов в книгах интересует только код. Остальные главы они почему-то не читают.

anton_z
Сообщения: 439
Зарегистрирован: 2017.01.15, 15:01

Re: С какой целью разрабатывается фреймворк

Сообщение anton_z » 2019.05.03, 14:29

ElisDN писал(а):
2019.05.03, 11:26
В чём лукавство?
В том что из замены $order->status = self::CLOSED на $order->close() никак не следует то, что используется DDD. Используется инкапсуляция и всё. Инкапсуляция может использоваться и без DDD.
ElisDN писал(а):
2019.05.03, 11:26
А если воспринимаете DDD как нечто техническое, заставляющее Вас использовать все паттерны, то значит прочли книгу не с той стороны. Как детей в книгах интересуют только картинки, так и программистов в книгах интересует только код. Остальные главы они почему-то не читают.
Это уже ваши домыслы. Меня удивляет ваша поляризация DDD - лапшекод. Есть много хорошего объектно-ориентированного ПО, которое создавалось без DDD, с этим спорить, надеюсь не будете?
ElisDN писал(а):
2019.05.03, 11:26
Так что сами контексты, доменный язык и доменные события для синхронизации - это не новомодная экзотика для гиков, а многолетняя обыденность каждого бизнеса.
Ага, только разрабы большинства ПО для этого бизнеса слышать не слышали про DDD. Вы еще и 1С как контекст к DDD притянули. :D Перечисленные системы могли быть созданы без единого упоминания о DDD. Так зачем оно нужно тогда, если и без него все норм и бизнес и так давно работает и системы интегрированы? Ловко вы все "скомбинировали", подвели обычное ПО предприятия под DDD.

ElisDN писал(а):
2019.05.03, 11:26

и в других определениях обратите внимание на слово "моделирование".
Реальность, модель и ПО (реализация) не тождественны. Да второе при построении может опираться на первое, а может быть быть сугубо абстрактным. ООП может быть использовано при реализации ПО на основе построенной модели, но формулировку
ElisDN писал(а):
2019.05.03, 02:52
называть объекты и их методы реальными именами, которыми их называет заказчик.
я нахожу уж слишком упрощенной и не отражающей сути.
ElisDN писал(а):
2019.05.03, 11:26
Все программы и программирование вообще используются для моделирования и формализации на компьютере чего-то из имеющихся вещей и процессов. Чтобы на нём решать практические жизненные задачи, а не чисто ради фана. А ООП вы возьмёте, ФП или процедурное - это уже какой стиль больше подойдёт. Для оперирования данными в математических задачах удобнее ФП, для моделирования объектов и взаимодействий удобнее ООП, для решения квадратного уравнения по действиям достаточно простыни императивного пошагового кода.
:D Это я давно уже знаю, можете не погружаться в основы и писать по существу.

P.S. Для большей ясности моей позиции, я считаю в DDD оверхедом две вещи:
1. Абстракция от базы. Реально пользы не видел. Сьедает время.
2. Фреймворконезависимость. Считаю, что это только для любителей программирования, концепт-пруфов и прочих никому не нужных вещей.

Все остальное из DDD может быть использовано с пользой, если без фанатизма.

Аватара пользователя
ElisDN
Сообщения: 5411
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN » 2019.05.03, 16:38

anton_z писал(а):
2019.05.03, 14:29
Это уже ваши домыслы. Меня удивляет ваша поляризация DDD - лапшекод. Есть много хорошего объектно-ориентированного ПО, которое создавалось без DDD, с этим спорить, надеюсь не будете?
А с чем здесь спорить? Это дополняющие вещи, а не противоположные.
anton_z писал(а):
2019.05.03, 14:29
Перечисленные системы могли быть созданы без единого упоминания о DDD. Так зачем оно нужно тогда, если и без него все норм и бизнес и так давно работает и системы интегрированы?
Если получилось в коде удобная объектная модель, приближенная к реальной предметной области, значит у них это и получилось по DDD. Знали ли они об этом или нет - не важно.
anton_z писал(а):
2019.05.03, 14:29
P.S. Для большей ясности моей позиции, я считаю в DDD оверхедом две вещи:
1. Абстракция сущностей от базы. Реально пользы не видел. Сьедает время.
2. Фреймворконезависимость. Считаю, что это только для любителей программирования, концепт-пруфов и прочих никому не нужных вещей.
Вот и говорю, что сами придумали - сами обиделись. DDD - это про менеджмент и моделирование, а не строго про программный код. В определении DDD про код конкретно ничего не написано кроме обозначения общих концепций. А отвязка от базы, фреймворконезависимость, CQRS, ES и прочее перечисленное - это сугубо опциональные вещи.

anton_z
Сообщения: 439
Зарегистрирован: 2017.01.15, 15:01

Re: С какой целью разрабатывается фреймворк

Сообщение anton_z » 2019.05.04, 03:11

ElisDN писал(а):
2019.05.03, 16:38
А с чем здесь спорить? Это дополняющие вещи, а не противоположные.
Тогда можно сделать вывод что ООП может существовать без DDD, нормальный код может существовать без DDD, тесты могут существовать без DDD. DDD вещь дополняющая. Вопрос: зачем нужен DDD если и без него можно получить хороший объектно-ориентированный код?
ElisDN писал(а):
2019.05.03, 16:38
Вот и говорю, что сами придумали - сами обиделись. DDD - это про менеджмент и моделирование, а не строго про программный код. В определении DDD про код конкретно ничего не написано кроме обозначения общих концепций. А отвязка от базы, фреймворконезависимость, CQRS, ES и прочее перечисленное - это сугубо опциональные вещи.
Про мою обиду это снова ваши домыслы. Никакой обиды ни на что у меня нет. О чем вы? Во вторых ничего я не придумывал. В книгах Вернона отвязка от базы и абстракция домена от инфраструктуры (фреймворка) описана как часть DDD. В примерах на github https://github.com/VaughnVernon/IDDD_Samples все это тоже есть. Книга Вернона считается основополагающей для DDD наравне с Эвансом. Или Вернон ошибается и он сам Эванса не понял?

P.S. Вспомнил что еще не нравится в DDD, так это методика Code First. По моему она ставит вещи с ног на голову. Посмотрим внимательнее на термин "data base". Что значит слово "base"? Оно означает "фундамент", "основа". Именно данные это основа большинства информационных систем, к коим и относятся большая часть всех приложений для бизнеса. Помню, на каком-то из Хайлоадов (речь о конференции) один докладчик говорил про то, что они нащупали универсальную методику разработки высоконагруженных систем. И первый вопрос на который они предлагают найти ответ: что у вас за данные? Так вот поэтому я считаю, что именно с данных и надо все начинать. Тем более что СУБД в последние годы не стоят на месте, а SQL это отличный декларативный язык, позволяющий удобно обрабатывать данные. После того, как база спроектирована, ООП нам поможет сделать хорошее приложение, помимо всего прочего генерирующее правильные запросы к СУБД. Конечно, по ходу разработки приложения в схему данных могут быть внесены корректировки, куда ж без них. А Code First нам предлагает базу воспринимать как что-то второстепенное, хотя это вещь важнейшая.

Аватара пользователя
ElisDN
Сообщения: 5411
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN » 2019.05.04, 12:30

anton_z писал(а):
2019.05.04, 03:11
Тогда можно сделать вывод что ООП может существовать без DDD, нормальный код может существовать без DDD, тесты могут существовать без DDD. DDD вещь дополняющая. Вопрос: зачем нужен DDD если и без него можно получить хороший объектно-ориентированный код?
Да, верно.

TDD и BDD - методология поверх тестов, советующая, как сделать тесты полезнее. Но тесты можно делать любыми способами без TDD и BDD. DDD - это методология поверх ООП, советующая, как спроектировать модель удобнее. ООП тоже можно делать как угодно без всяких DDD.

TDD лишь дополнительно советует делать тесты одновременно с кодом. BDD говорит записывать тесты языком человекочитаемых юзкейсов. DDD говорит делить сложные системы на контексты, выработать общий язык и придерживаться этого языка при проектировании объектов.
ElisDN писал(а):
2019.05.03, 16:38
В книгах Вернона отвязка от базы и абстракция домена от инфраструктуры (фреймворка) описана как часть DDD. В примерах на github все это тоже есть. Книга Вернона считается основополагающей для DDD наравне с Эвансом. Или Вернон ошибается и он сам Эванса не понял?
Ключевое - абстракция домена от нечистых технических вещей. Инкапсуляция всего технического в инфраструктуру. Чтобы думать смыслами, а не деталями.

Вот недо-ООП-код без DDD:

Код: Выделить всё

public function handle(Command $command): void
{
    $email = mb_strtolower($command->email);
    if ($this->em->getRepository(User::class)->findOneBy(['email' => $email])) {
        throw new \LogicException('User already exists.');
    }
    $user = new User();
    $user->setId(Uuid::uuid4()->toString());
    $user->setDate(new \DateTimeImmutable());
    $user->setEmail($email);
    $user->setPasswordHash(password_hash($command->password, PASSWORD_ARGON2I));
    $user->setConfirmToken(bin2hex(random_bytes(16));
    $user->setStatus(User::STATUS_WAIT);
    $this->em->persist($user);
    $this->em->flush();
    $message = (new \Swift_Message('Sig Up Confirmation'))
        ->setTo($email)
        ->setBody($this->twig->render('mail/user/signup.html.twig', ['token' => $token]), 'text/html');
     $this->mailer->send($message);
 }
Вот ООП-код с DDD:

Код: Выделить всё

public function handle(Command $command): void
{
    $email = new Email($command->email);
    if ($this->users->hasByEmail($email)) {
        throw new UserAlreadyExistsException();
    }
    $user = User::signUpByEmail(
        Id::next(),
        new \DateTimeImmutable(),
        $command->username,
        $email,
        $this->hasher->hash($command->password),
        $token = $this->tokenizer->generate()
    );
    $this->users->add($user);
    $this->sender->send($email, $token);
}
Коды делают то же самое.

Но в первом программист бездумно клепал как есть и получилось, что всё идёт простынёй вперемешку с непонятными техническими bin2hex и PASSWORD_ARGON2I и Swift_Mailer.

А во втором программист по-настоящему заморочился с ООП и все эти инфраструктурные вещи вроде bin2hex(random_bytes(16)) инкапсулировал в понятные абстракции по смыслу вроде $tokenizer->generate(). И получил компактный понятный человекочитаемый код, очищенный от неинтересного технического мусора. Даже уборщица в любой строке разберётся.

И, как бонус, код второго метода handle теперь автоматически получился фреймворконезависимым, так как теперь внутри TokenSender::send можно спокойно заменить SwiftMailer на Mailgun API. Да и даже с PHP в Java можно один-в-один перенести, поправив синтаксис.

Так что фреймворконезависимость здесь оказалась не целью, а результатом. Если при продумывании ООП-модели так думать о домене, то естественным образом получается DDD-совместимый ООП-код.
anton_z писал(а):
2019.05.04, 03:11
P.S. Вспомнил что еще не нравится в DDD, так это методика Code First. По моему она ставит вещи с ног на голову. Посмотрим внимательнее на термин "data base". Что значит слово "base"? Оно означает "фундамент", "основа".
Это как у Задорнова "стоматолог = матершинник", а "голосистая = девушка без бюстгальтера".
anton_z писал(а):
2019.05.04, 03:11
Именно данные это основа большинства информационных систем, к коим и относятся большая часть всех приложений для бизнеса. Помню, на каком-то из Хайлоадов (речь о конференции) один докладчик говорил про то, что они нащупали универсальную методику разработки высоконагруженных систем. И первый вопрос на который они предлагают найти ответ: что у вас за данные? Так вот поэтому я считаю, что именно с данных и надо все начинать.
Ещё он говорил, что ваш код - это прослойка между браузером и БД.

Если это информационная система, записывающая и предоставляющая информацию, то её основа - это хранение статических данных. Надо начинать с раскладывания данных и можно забить на то, какая неудобная админка для их вбивания.

Если это система автоматизация бизнеса, то её основа - алгоритмы динамических бизнес-процессов. Надо начинать с бизнес-процессов и можно забить на то, как и где они хранятся. Хоть в file_put_contents(..., serialize($object)).

Так что не смешивайте всё в одну кучу.
anton_z писал(а):
2019.05.04, 03:11
Тем более что СУБД в последние годы не стоят на месте, а SQL это отличный декларативный язык, позволяющий удобно обрабатывать данные. После того, как база спроектирована, ООП нам поможет сделать хорошее приложение, помимо всего прочего генерирующее правильные запросы к СУБД. Конечно, по ходу разработки приложения в схему данных могут быть внесены корректировки, куда ж без них.
Это просто сказывается ваша зацикленность только на табличных SQL базах. Вы все таблицы, значения, документы, графы и объекты загоняете костылями в MySQL. Вместо того, чтобы для таблиц, значений, документов, графов и объектов использовать специально для них придуманные табличные, key-value, документные, графовые и объектные БД.
anton_z писал(а):
2019.05.04, 03:11
А Code First нам предлагает базу воспринимать как что-то второстепенное, хотя это вещь важнейшая.
Повторюсь. что не всегда эта вещь важнейшая.

Если кода мало, то CRUD с DB-First. Если кода много, то Domain Model с Code First.

anton_z
Сообщения: 439
Зарегистрирован: 2017.01.15, 15:01

Re: С какой целью разрабатывается фреймворк

Сообщение anton_z » 2019.05.04, 13:29

ElisDN писал(а):
2019.05.04, 12:30

Вот недо-ООП-код без DDD:
А в существование хорошего ООП кода без DDD не верите? Вы как-то поляризуете: говнокод - DDD? Третьего по-вашему нет?
ElisDN писал(а):
2019.05.04, 12:30

Ключевое - абстракция домена от нечистых технических вещей. Инкапсуляция всего технического в инфраструктуру. Чтобы думать смыслами, а не деталями.

Так вот на эту абстракцию домена тратится слишком много времени, польза от этого в проектах с небольшой командой сомнительна. Прошу учитывать, что это не про абстракцию вообще, а про абстракцию домена в DDD.
ElisDN писал(а):
2019.05.04, 12:30

Даже уборщица в любой строке разберётся.
Ой, не смешите. :D Сказки про то, что код надо писать так, чтоб его поняли менеджеры я уже слышал. Да ни один управленец даже не подумает об этом и скажет что код это ваша работа, что вы меня им грузите.
ElisDN писал(а):
2019.05.04, 12:30

Это как у Задорнова "стоматолог = матершинник", а "голосистая = девушка без бюстгальтера".
Я с вами по существу говорю, ваших фельетонов не понимаю, с этим на другой форум надо.
ElisDN писал(а):
2019.05.04, 12:30

Если это информационная система, записывающая и предоставляющая информацию, то её основа - это хранение статических данных. Надо начинать с раскладывания данных и можно забить на то, какая неудобная админка для их вбивания.

Если это система автоматизация бизнеса, то её основа - алгоритмы динамических бизнес-процессов. Надо начинать с бизнес-процессов и можно забить на то, как и где они хранятся.
Не согласен. Определение информационной системы. https://ru.wikipedia.org/wiki/Информационная_система. Это понятие очень широкое. Под него большинство сайтов и приложений подойдет.
ElisDN писал(а):
2019.05.04, 12:30

Это просто сказывается ваша зацикленность только на табличных SQL базах. Вы все таблицы, значения, документы, графы и объекты загоняете костылями в MySQL. Вместо того, чтобы для таблиц, значений, документов, графов и объектов использовать специально для них придуманные табличные, key-value, документные, графовые и объектные БД.
Я где-то говорил, что графы и документы костылями загоняю в MySQL? У меня нет зацикленности. Вы постоянно домысливаете, попрошу не приписывать мне того, чего я не говорил.
ElisDN писал(а):
2019.05.04, 12:30

Если кода мало, то CRUD с DB-First. Если кода много, то Domain Model с Code First.
Каждому свое. Я считаю, что Code First непригоден для информационных систем, где в основе - обработка данных. Для для геймдева, настольных приложений может и ничего, но я последними не занимаюсь. Похожих мнений встречал не мало, в том числе на этом форуме.

Аватара пользователя
ElisDN
Сообщения: 5411
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN » 2019.05.04, 16:27

anton_z писал(а):
2019.05.04, 13:29
А в существование хорошего ООП кода без DDD не верите? Вы как-то поляризуете: говнокод - DDD? Третьего по-вашему нет?
Во что не верю? Я наоборот говорю, что хороший (канонический) ООП по определению естественным путём реализует DDD. Почти синонимы.

А вы нам всеми силами эти синонимы противопоставлять пытаетесь. Что вы за ООП, но против DDD.

anton_z
Сообщения: 439
Зарегистрирован: 2017.01.15, 15:01

Re: С какой целью разрабатывается фреймворк

Сообщение anton_z » 2019.05.05, 06:58

ElisDN писал(а):
2019.05.04, 16:27
Во что не верю? Я наоборот говорю, что хороший (канонический) ООП по определению естественным путём реализует DDD. Почти синонимы.

А вы нам всеми силами эти синонимы противопоставлять пытаетесь. Что вы за ООП, но против DDD.
ООП и DDD не синонимы.

ООП - парадигма программирования.

DDD - подход к разработке ПО, предполагающий сближение модели предметной области и реализации.

1. DDD предполагает реализацию паттерна Doman Model, ООП само по себе как парадигма программирования не содержит паттернов.

2. В ООП можно делать классы не руководствуясь предметной областью (хотя оно бывает удобно). Всякие адаптеры, фабрики и прочие классы, их в предметной области нет и быть не может, но они есть и пишутся с использованием ООП.

3. Можно реализовать проект не используя Domain Model. а используя RowDataGateway, От отсутствия DomainModel код с правильно распределенными обязанностями (по GRASP например) не перестанет быть объектно-ориентированным. Т.е. выделить абстракцию в виде объекта можно по любым критериям, которые придумает программист, а не только по предметной области.

4. DDD можно делать и вовсе без ООП. Просто ООП хорошо подходит для DDD.

Какие же это синонимы? Это разные вещи.

uEhlO4a
Сообщения: 61
Зарегистрирован: 2017.08.12, 19:19

Re: С какой целью разрабатывается фреймворк

Сообщение uEhlO4a » 2019.05.08, 19:05

о, лютая тема жива! подкину дров..

А мне нравится больше "недо-ООП-код без DDD". В одной функции понятно что происходит и не нужно 10 минут лазить по пачке файлов.

что такое $this->users ?
какой нафиг Id::next() ? Это DDD ? Нет, это пиздец.

Также

Код: Выделить всё

$email = new Email($command->email);
$this->sender->send($email, $token);
- это не ООП, а покруче говнокод примера выше

если мы говорим об ООП, то должно быть

Код: Выделить всё

$email = new SignupEmail($user, $token)
Mailer::send($email)  / $this->mailer->send($email)
а лучше вообще если

Код: Выделить всё

$email = new SignupEmail($user)
самое смешное, что во 2м варианте такая же лажа с транзакциями как и в первом. Так что не стоит 1й вариант обзывать, он намного лучше 2го при всех равных. ха-ха

uEhlO4a
Сообщения: 61
Зарегистрирован: 2017.08.12, 19:19

Re: С какой целью разрабатывается фреймворк

Сообщение uEhlO4a » 2019.05.08, 20:00

пожалуйста покажите мне, в какой момент код стало легче читать чем "недо-ООП-код без DDD" ?

Код: Выделить всё


<?php

//
// DDD
//
class A {
    public function handle(Command $command): void
    {
        try {
            $newUser = UserManager::signupByEmail(mb_strtolower($command->email), $command->password);
        } catch (\UserAlreadyExistsException $e) {
        } catch (\Throwable $t) {
        }
    }
}

//
//
// DDD OOP NE-POLOTNO NE-GOVNOKOD
//
//
class UserAlreadyExistsException extends \Exception {}

trait Twigable {
    function getTwig() {
        return new class() extends \StdClass { function render($a) {return 'Yo!';}};
    }
}
class Command {
    public $email;
}

interface ISender {
    function send(IEmail $emailMessage);
}
interface IEmail {
    function send(ISender $sender);
}

class SignupEmail implements IEmail { // <--- WRAPPER
    use Twigable;
    public $message;
    public $token;
    function __construct(User $user) {
        $this->token = bin2hex(random_bytes(16));
        $this->message = (new Swift_Message('Sig Up Confirmation'))
            ->setBody($this->getTwig()->render('mail/user/signup.html.twig', ['token' => $this->token]), 'text/html')
            ->addTo($user->getEmail());
    }

    function send(ISender $sender) {
        return $sender->send($this->message);
    }
}

/**
 * @method getEmail()
 * @method setId($a)
 * @method setDate($a)
 * @method setPasswordHash($a)
 * @method setStatus($a)
 * @method setConfirmToken($a)
 * @method setEmail($a)
 */
class User {
    const STATUS_WAIT = 1;
    function __call($name, $arguments) {
    }
}

class UserManager { // <--- недо-ООП-код без DDD
    static $em;
    /** @var ISender */
    static $sender;
    static function signupByEmail($email, $password, &$sentEmail) {
        $em = self::em;
        if ($em->getRepository(User::class)->findOneBy(['email' => $email])) {
            throw new \UserAlreadyExistsException('User already exists.');
        }
        $em->getConnection()->beginTransaction();
        try {
            $user = new User();
            $user->setId(\Ramsey\Uuid\Uuid::uuid4());
            $user->setDate(new \Datetime());
            $user->setEmail($email);
            $user->setPasswordHash(password_hash($password, PASSWORD_ARGON2I));
            $user->setStatus(User::STATUS_WAIT);
                        
            $sentEmail = new SignupEmail($user);
            self::$sender->send($sentEmail);
            
            $user->setConfirmToken($sentEmail->token);
            
            $em->persist($user);
            
            $em->flush();
            $em->getConnection()->commit();
        } catch (\Throwable $t) {
            $em->getConnection()->rollBack();
            throw $t;
        }
    }
}


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

п.с.
Есть тут компании у кого штат над проектом хотя бы 20+ человек? Интересно узнать ваш опыт (20 сотрудников кто пишет код и проектирует, уборщицы и менеджмент не в счет)
Последний раз редактировалось uEhlO4a 2019.05.08, 20:54, всего редактировалось 2 раза.

uEhlO4a
Сообщения: 61
Зарегистрирован: 2017.08.12, 19:19

Re: С какой целью разрабатывается фреймворк

Сообщение uEhlO4a » 2019.05.08, 20:21

anton_z писал(а):
2019.05.04, 13:29
Ой, не смешите. :D Сказки про то, что код надо писать так, чтоб его поняли менеджеры я уже слышал. Да ни один управленец даже не подумает об этом и скажет что код это ваша работа, что вы меня им грузите.
тут не соглашусь. В конкретной области нужен такой дядя или тетя как "domain expert", по-простому, один из тех кого можно грузить вопросами по теме. Как правило сюда вклиниваются лапшевесы вроде "project analytic" и "project lead/manager" и потом это пытаются пересказать "project manager". а тот потом говорит "я нифига не понял, на читай доку, там всё описано"

так что код должен отражать реальность. вопрос только какую реальность оно будет отражать зависит от разработчика на процентов 20%, наличие бубна и других средств конечно повышает шансы на более точную проекцию, но даже в таких случаях клиент всё равно что-то изменит.
Последний раз редактировалось uEhlO4a 2019.05.08, 20:35, всего редактировалось 1 раз.

uEhlO4a
Сообщения: 61
Зарегистрирован: 2017.08.12, 19:19

Re: С какой целью разрабатывается фреймворк

Сообщение uEhlO4a » 2019.05.08, 20:28

maleks писал(а):
2019.05.01, 14:50
Не записывали себе какие то знаковые статьи/обсуждения на эту тему?
если нечего делать более приятного, то можно зайти сюда https://github.com/heynickc/awesome-ddd

Аватара пользователя
ElisDN
Сообщения: 5411
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN » 2019.05.09, 00:39

uEhlO4a писал(а):
2019.05.08, 20:00
пожалуйста покажите мне, в какой момент код стало легче читать чем "недо-ООП-код без DDD" ?
Нормально читается и с транзакцией:

Код: Выделить всё

class Handler
{
    public function __construct(
        UserRepository $users,
        PasswordHasher $hasher,
        SignUpTokenizer $tokenizer,
        Transaction $transaction,
        SignUpTokenSender $sender
    ) {
        $this->users = $users;
        ...
    }

    public function handle(Command $command): void
    {
        $email = new Email($command->email);
        
        if ($this->users->hasByEmail($email)) {
            throw new UserAlreadyExistsException();
        }
        
        $user = User::signUpByEmail(
            Id::next(),
            new \DateTimeImmutable(),
            $command->username,
            $email,
            $this->hasher->hash($command->password),
            $this->tokenizer->generate()
        );
        
        $this->transaction->wrap(function () use ($user) {
            $this->users->add($user);
            $this->sender->send($user->getEmail(), $user->getConfirmToken());
        });
    }
}

Код: Выделить всё

class SignUpTokenSender
{
    private $mailer;
    private $twig;

    public function __construct(\Swift_Mailer $mailer, \Twig\Environment $twig)
    {
        $this->mailer = $mailer;
        $this->twig = $twig;
    }

    public function send(Email $email, string $token): void
    {
        $message = (new \Swift_Message('Sig Up Confirmation'))
            ->setTo($email->getRaw())
            ->setBody($this->twig->render('mail/user/signup.html.twig', ['token' => $token]), 'text/html');
            
        $this->mailer->send($message);
    }
}
Безо всяких ваших трейтов, синглтонов и циклических зависимостей.

По классам мотаться незачем, так как из названий понятно, что они делают.

Ответить