Я вот так и не смог понять про какую такую бизнес-логику все в таких статьях говорят
Ну можно как то так понять: берем некие бизнес процессы существующие оффлайн, моделируем их через программные сущности. Правила их взаимодействий, требования к их состояниям - бизнес логика. Для такого моделирования не требуется БД, она нужна для хранения данных. И вот, прикручиваем БД так, чтоб модель про нее ничего не знала.
Да есть просто подход такой к неймингу в коллекциях, иммется ввиду findById() / getById() в семантике find - "поищи, оно там может быть", get - "дай, оно там есть". Соответственно в первом случае может быть null, во втором если ключа нет - что то пошло не так, исключение.
Видимо имеется ввиду, что сперва мы строим пирамиду, а потом, когда решаем сделать её повыше с сохранением пропорций, то добавляем кирпичей в каждый уровень, начиная с основания.
Из личного опыта: 350 развитых растений земляники садовой (в избытке имеющих питание и свет) недостаточно для удержания уровня CO2 ниже 1000 ppm в условно герметичном помещении, при наличии в нём же взрослого человека занимающегося легкой физ активностью.
Так что не стоит возлагать даже малейшие надежды на растения в условиях квартиры в вопросе рекуперации CO2. Впрочем так же не стоит и переживать об удушье (из за растений же) в ночные часы.
Нда? А что там насчёт однояйцевых близнецов? По вашему их максимально возможная разница в темпераменте будет около 0%, а в характере около 50%. Не смущает?
50% черт характера - это не половина личности, характер и темперамент - это только её часть.
прадедушка был лихой разбойник и его гены проявились в правнуке, и он вырастит бандитом
А что есть ген разбойничества или хотя бы черта характера "бандитсво"?
Прадед пошёл грабить не по приколу, а, потому что есть было нечего, был обманут - поэтому считал что имеет право, имел дружков таких же - поэтому ощущал возможность.
Варианты человеческой деятельности слишком сложны чтоб наследоваться. Характер это же набор довольно простых типичных реакций, которые тоже сами по себе мало что определяют. И бандиты, внезапно, тоже имеют разные характеры и как то не видно ограничений на то, чтоб какая та черта была категорически несовместима с такой деятельностью.
А где же дтошка соответствующая финальному тесту? Та что приводится вначале не пройдёт его вторую половину, её можно создать из пустого массива, по тестам должна быть ошибка.
Вот она, долгожданная финальная структура теста, который можно затащить к себе в проект
Серьёзно? Закроем глаза на то что это тест дто (и на то что не того, что в статье), но вот он в остальном таком виде вас устраивает в проекте?
Там треть методов имеют идентичное тело и вводят в заблуждение своим именем - по именам набора тестов можно предположить, что каждое поле в дто обязательно, по факту же проверяемый объект для удовлетворения этим тестам должен допускать отсутствие любого поля в момент создания, но не всех одновременно. Кроме того, протестировано создание с частичным присутствием полей, но не протестирована логика чтения отсутствующего поля.
И это всё подозрительно. Скорее всего тест некорректен, а объект позволяет слишком многое.
Теперь про исходную дтошку. Прекрасная штука. Жрёт на вход что угодно, лишь бы в массиве и помалкивает, бережно хранит всё это в себе, даже если оно ей не упёрлось, вытаскиваем содержимое по ключу, но зачем то через хэлпер Arr, падаем только при несоответствии типов в момент чтения и то при strict_types=1. То есть по системе могут гулять захламленные лишними данными, невалидные объекты и наткнемся мы на ошибку в непредсказуемый момент в непредсказуемом месте. Читать чудо дтошку надо видимо в try catch.
Ну и вишенка - статанализ видимо в проекте отсутствует.
как не делать 1-2 часа 5 минутную задачу
final readonly class UserCrmDto
{
public function __construct(
private string $phone,
private string $id,
private string $pwd,
...
) {
}
}
Из-за бедных голодающих детей? Точно ли нет других причин? И действительно ли нужно кушать всякий раз и всякую еду по прихоти другого человека?
Почему из вашей "системы координат" выходит, что преувеличенная проблема - это нежелание ребенка съесть то что и когда велено, а не проблема отца в виде непоевшего ребенка? Ведь применить вашу систему можно и так: "разве это серьезная проблема, что ребенок не поел по своему желанию, когда в мире столько голодающих детей".
Монарх был главным феодалом, все остальные были у него в подчинении. И буржуазия претендовала именно на этот высший пост, а не на подчинённый кому-либо.
Вот в том и дело, что всю дорогу на высший пост претендовал кто угодно имеющий ресурс для этого.
В разные времена люди находили поводы для войны. Я же говорил конкретно про нации и национализм. Это - изобретение капитализма.
И снова, если правители всё время находили поводы для разделения и властвования, то не требуется вводить влияние капитализма для обоснования причин появления национальных идей. Любой, кто имеет амбиции правителя и видит в национальных идеях источник легитимации или влияния, имеет и мотив взять эти идеи на своё вооружение.
При феодализме был один феодал - монарх, он владел всем в государстве. При капитализме есть пусть небольшая, но группа капиталистов, каждый из которых хочет стать монархом и получить его возможности и привилегии. Но страна одна, а претендентов много. Именно поэтому при становлении капитализма происходит дробление территорий, где капиталисты становятся такими царьками, каждый на своём участке.
Это сюжет какого то фэнтези или откуда вы это взяли? Феодалом мог стать любой способный захватить и удерживать кусок земли, кусок земли так же мог быть в составе более крупной формации и мог быть пожалован феодалу сюзереном. В итоге была постоянная конкуренция между претендентами на статус феодала, феодалов между собой, феодалов с их сюзереном, соседними феодалами и сюзеренами и тд. Феоды возникали, объединялись и дробились постоянно.
Ничего даже отдалено похожего "при капитализме" на системном уровне не наблюдается. Но вовсе не потому что они такие хорошие, а потому что необходимость в оспаривании границ стала намного ниже после индустриализации и глобализации рынков. Ресурсы ради которых враждовали феодалы были все исключительно привязаны к земле и приращивались вместе с ней, в настоящее же время весьма глупо будет пытаться захватить часть другой страны ради её высокотехнологичной промышленности. Потому что квалифицированная рабочая сила при этом разбежится, поставщики сырья и оборудования введут санкции, а сами предприятия будут уничтожены во время военных действий.
А самый простой способ размежевать людей и стравить их - разделить по национальному признаку. Так что нация, национальность - это изобретение капитализма.
В этих утверждениях можно заменить "нация" на "религия" без изменения смысла, выходит религию тоже капиталисты изобрели. Логика.
Так ведь и написано "страшный сон", тогда как для кого то в команде это уже не сон, а страшная реальность )
Там вроде ничего нет про будить среди ночи, просто выражение такое. И в общем то справедливо, критичный баг на проде - стрессовая ситуация для всех в команде, кто был задействован в дефектном выпуске и будет задействован в выпуске фикса, так что и для тестировщика тоже.
Это вы просто знаете что функция использует http и какой пакет в добавок. А могли и не знать, так что проблема не в кастомных исключениях. Были бы исключения в каком то виде перечислены и всё было бы ок независимо от их кастомности или наличия у вас доп знаний.
Статья странновато написана, возможно от этого часть недопонимания в комментах. Не надо воспринимать это как живопись, это концептуальный перфоманс. Художник делает невыполнимую задачу много лет, до самой смерти, цель - вызвать мысли и ощущения из ряда о бесконечности, месте человека в ней и тп. Если вам это кажется бессмысленным, то это тоже эффект: что как не бессмысленность есть любое действие человека в масштабах бесконечности ¯\_(ツ)_/¯
Бизнес ничего не знает про уровень приложения и не-приложения.
Ну как же, ещё как знает. У бизнеса есть процессы которые могут работать без программы - это и есть предметная область у неё уже есть сущности, их связи, регламенты, правила - всё это будет необходимо смоделировать. Бизнес хочет автоматизировать эти процессы, заказывает программу и добавляет специфичные для программы требования - это и будут требования уровня приложения.
Бизнес, например, может заказать несколько программ (или подпрограмм), чтоб они работали с одними и теми же сущностями но разным образом. Вот тут и работает наша модель и её чистота от требований к приложению.
Роберт Мартин пишет про это в чистой архитектуре так: "A use case is a description of the way that an automated system is used. It specifies the input to be provided by the user, the output to be returned to the user, and the processing steps involved in producing that output. A use case describes application-specific business rules as opposed to the Critical Business Rules within the Entities."
Если загрязнять домен требованиями, которые относятся к приложению, то получаем всё те же недостатки God Object просто размазанные по сервисам - грязный, хрупкий, неповоротливый домен с запутанными связями.
Впрочем, это нормальный подход для небольших и не сложных систем, но всё же, заголовок статьи о других подходах.
Вот я как раз говорю, что сервис это самое подходящее место, аргументы привожу. "Скорее всего" как-то не выглядит весомым аргументом)
"Скорее всего" - во первых потому что обычно сервис избыточен, поскольку большинство действий соответствуют одной сущности и идеально выражаются через её методы. Во вторых, сервис будет необходим при комплексных действиях, но не каждый такой случай потребует контроля особых инвариантов, сервис часто будет только работать с методами сущностей которые как и прежде контролируют свои инварианты.
Помещать в модель свои действия и контроль своих инвариантов предпочтительнее по причинам самодостаточности и удобства восприятия. Можно, наверное, сойтись на том что это вкусовщина и вынос всех действий в сервисы - просто другой подход к организации кода, но вот загрязнение этих доменных сервисов побочками, внесение их в домен на ровне с бизнес правилами предметной области - это совсем никуда не годиться, по крайней мере в контексте кейвордов из заголовка статьи.
Зависимость между слоями направлена сверху вниз. Infrastructure layer в структуре слоёв лежит ниже Domain layer и соответственно объекты Infrastructure layer не смогут увидеть интерфейсы Infrastructure layer, которые описаны в Domain layer
Схему можно по разному нарисовать, часто изображают слои вложенными окружностями и тогда зависимость направлена снаружи - вглубь. Доменный слой - самый глубокий.
В статье на схеме зависимости отображены сплошными стрелками, что там нарисовано выше или ниже - смысловой нагрузки не имеет.
Репозитории находятся в инфраструктуре и реализуют интерфейсы определенные в домене - это отражает то, что реализация хранилища объекта домена зависит от домена и может существовать более одной реализации.
Вы забываете, что бизнес правила имеют деление. Есть бизнес правила относящиеся к предметной области, есть относящиеся к приложению.
Отправка письма при неком действии - это типичное бизнес правило уровня приложения, при разделении на слои контроль этого правила собственно и окажется в слое application.
Установка текущей даты при создании сущности - будет относится к уровню домена если нам необходимо гарантировать что у нас не должно быть возможным наличие сущности хранящей в себе дату отличающейся от фактической даты её создания. То есть, например, когда при создании сущности мы не можем передать эту дату на уровень домена извне.
Для разных сценариев могут быть разные требования. Например админу в админке можно не заполнять какие-то поля, а пользователю нельзя
Это именно что разные use cases и требования к ним, разрешаются на уровне приложения и никак не связаны с требованиям к модели предметной области. То есть в разных кейсах могут быть разные поля и требования к ним, но они в итоге должны привести к созданию модели удовлетворяющим глобальным требованиям. Если взять предыдущий пример, когда контроль даты создания - требование к модели, то какими бы небыли различными наборы полей в разных кейсах, дату создания задать через них не выйдет.
То есть инварианты для OrderItem могут соблюдаться в другом классе Order, вне сущности OrderItem. Почему тогда инварианты для сущности Order не могут быть вне неё, в OrderService?
Инварианты должны гарантироваться на уровне домена, если сервис находится там, то технически он может взять на себя контроль какого то инварианта, но скорее всего для этого найдётся место получше.
DDD подразумевает моделирование предметной области, когда требование - часть предметной области, оно тоже попадает в модель. Так что всё же, если речь про DDD, то целостность и непротиворечивость, в той мере, в которой они выражаются в предметной области, нас при проектировании интересуют и не меньше чем сами данные.
На масштабе эти результаты дадут ответ на вопрос о самых неудачных курсах
Не дадут. Абсолютно бесполезное голосование. Большие цифры будут у более известных среди аудитории. Поправка на трафик ещё одна бесполезная процедура. Кроме того, у одной площадки могут быть как плохие так и хорошие курсы.
В общем, мусор на входе - мусор на выходе.
Как отмечено выше правильная методика - это дать возможность респондентам выбрать (или ввести самостоятельно) конкретный курс и дать ему оценку. Потом по этим данным можно было бы оценить и популярность и качество.
Принципиальной для обучения разницы между версиями нет. Изучать версии курсами не имеет смысла. Если курсы одного качества, проходите тот, что свежее, разницу между версиями посмотрите по обзорам изменений.
Ну можно как то так понять: берем некие бизнес процессы существующие оффлайн, моделируем их через программные сущности. Правила их взаимодействий, требования к их состояниям - бизнес логика. Для такого моделирования не требуется БД, она нужна для хранения данных. И вот, прикручиваем БД так, чтоб модель про нее ничего не знала.
Да есть просто подход такой к неймингу в коллекциях, иммется ввиду findById() / getById() в семантике find - "поищи, оно там может быть", get - "дай, оно там есть". Соответственно в первом случае может быть null, во втором если ключа нет - что то пошло не так, исключение.
Видимо имеется ввиду, что сперва мы строим пирамиду, а потом, когда решаем сделать её повыше с сохранением пропорций, то добавляем кирпичей в каждый уровень, начиная с основания.
Из личного опыта: 350 развитых растений земляники садовой (в избытке имеющих питание и свет) недостаточно для удержания уровня CO2 ниже 1000 ppm в условно герметичном помещении, при наличии в нём же взрослого человека занимающегося легкой физ активностью.
Так что не стоит возлагать даже малейшие надежды на растения в условиях квартиры в вопросе рекуперации CO2. Впрочем так же не стоит и переживать об удушье (из за растений же) в ночные часы.
Нда? А что там насчёт однояйцевых близнецов? По вашему их максимально возможная разница в темпераменте будет около 0%, а в характере около 50%. Не смущает?
50% черт характера - это не половина личности, характер и темперамент - это только её часть.
А что есть ген разбойничества или хотя бы черта характера "бандитсво"?
Прадед пошёл грабить не по приколу, а, потому что есть было нечего, был обманут - поэтому считал что имеет право, имел дружков таких же - поэтому ощущал возможность.
Варианты человеческой деятельности слишком сложны чтоб наследоваться. Характер это же набор довольно простых типичных реакций, которые тоже сами по себе мало что определяют. И бандиты, внезапно, тоже имеют разные характеры и как то не видно ограничений на то, чтоб какая та черта была категорически несовместима с такой деятельностью.
А где же дтошка соответствующая финальному тесту? Та что приводится вначале не пройдёт его вторую половину, её можно создать из пустого массива, по тестам должна быть ошибка.
Серьёзно? Закроем глаза на то что это тест дто (и на то что не того, что в статье), но вот он в остальном таком виде вас устраивает в проекте?
Там треть методов имеют идентичное тело и вводят в заблуждение своим именем - по именам набора тестов можно предположить, что каждое поле в дто обязательно, по факту же проверяемый объект для удовлетворения этим тестам должен допускать отсутствие любого поля в момент создания, но не всех одновременно. Кроме того, протестировано создание с частичным присутствием полей, но не протестирована логика чтения отсутствующего поля.
И это всё подозрительно. Скорее всего тест некорректен, а объект позволяет слишком многое.
Теперь про исходную дтошку. Прекрасная штука. Жрёт на вход что угодно, лишь бы в массиве и помалкивает, бережно хранит всё это в себе, даже если оно ей не упёрлось, вытаскиваем содержимое по ключу, но зачем то через хэлпер Arr, падаем только при несоответствии типов в момент чтения и то при strict_types=1. То есть по системе могут гулять захламленные лишними данными, невалидные объекты и наткнемся мы на ошибку в непредсказуемый момент в непредсказуемом месте. Читать чудо дтошку надо видимо в try catch.
Ну и вишенка - статанализ видимо в проекте отсутствует.
тесты не требуются.
Из-за бедных голодающих детей? Точно ли нет других причин? И действительно ли нужно кушать всякий раз и всякую еду по прихоти другого человека?
Почему из вашей "системы координат" выходит, что преувеличенная проблема - это нежелание ребенка съесть то что и когда велено, а не проблема отца в виде непоевшего ребенка? Ведь применить вашу систему можно и так: "разве это серьезная проблема, что ребенок не поел по своему желанию, когда в мире столько голодающих детей".
Вот в том и дело, что всю дорогу на высший пост претендовал кто угодно имеющий ресурс для этого.
И снова, если правители всё время находили поводы для разделения и властвования, то не требуется вводить влияние капитализма для обоснования причин появления национальных идей. Любой, кто имеет амбиции правителя и видит в национальных идеях источник легитимации или влияния, имеет и мотив взять эти идеи на своё вооружение.
Это сюжет какого то фэнтези или откуда вы это взяли? Феодалом мог стать любой способный захватить и удерживать кусок земли, кусок земли так же мог быть в составе более крупной формации и мог быть пожалован феодалу сюзереном. В итоге была постоянная конкуренция между претендентами на статус феодала, феодалов между собой, феодалов с их сюзереном, соседними феодалами и сюзеренами и тд. Феоды возникали, объединялись и дробились постоянно.
Ничего даже отдалено похожего "при капитализме" на системном уровне не наблюдается. Но вовсе не потому что они такие хорошие, а потому что необходимость в оспаривании границ стала намного ниже после индустриализации и глобализации рынков. Ресурсы ради которых враждовали феодалы были все исключительно привязаны к земле и приращивались вместе с ней, в настоящее же время весьма глупо будет пытаться захватить часть другой страны ради её высокотехнологичной промышленности. Потому что квалифицированная рабочая сила при этом разбежится, поставщики сырья и оборудования введут санкции, а сами предприятия будут уничтожены во время военных действий.
В этих утверждениях можно заменить "нация" на "религия" без изменения смысла, выходит религию тоже капиталисты изобрели. Логика.
Так ведь и написано "страшный сон", тогда как для кого то в команде это уже не сон, а страшная реальность )
Там вроде ничего нет про будить среди ночи, просто выражение такое. И в общем то справедливо, критичный баг на проде - стрессовая ситуация для всех в команде, кто был задействован в дефектном выпуске и будет задействован в выпуске фикса, так что и для тестировщика тоже.
Это вы просто знаете что функция использует http и какой пакет в добавок. А могли и не знать, так что проблема не в кастомных исключениях. Были бы исключения в каком то виде перечислены и всё было бы ок независимо от их кастомности или наличия у вас доп знаний.
Статья странновато написана, возможно от этого часть недопонимания в комментах. Не надо воспринимать это как живопись, это концептуальный перфоманс. Художник делает невыполнимую задачу много лет, до самой смерти, цель - вызвать мысли и ощущения из ряда о бесконечности, месте человека в ней и тп. Если вам это кажется бессмысленным, то это тоже эффект: что как не бессмысленность есть любое действие человека в масштабах бесконечности ¯\_(ツ)_/¯
В 1995 открыли, наблюдать её во всей красе можно было в 1997.
Ну как же, ещё как знает. У бизнеса есть процессы которые могут работать без программы - это и есть предметная область у неё уже есть сущности, их связи, регламенты, правила - всё это будет необходимо смоделировать. Бизнес хочет автоматизировать эти процессы, заказывает программу и добавляет специфичные для программы требования - это и будут требования уровня приложения.
Бизнес, например, может заказать несколько программ (или подпрограмм), чтоб они работали с одними и теми же сущностями но разным образом. Вот тут и работает наша модель и её чистота от требований к приложению.
Роберт Мартин пишет про это в чистой архитектуре так: "A use case is a description of the way that an automated system is used. It specifies the input to be provided by the user, the output to be returned to the user, and the processing steps involved in producing that output. A use case describes application-specific business rules as opposed to the Critical Business Rules within the Entities."
Если загрязнять домен требованиями, которые относятся к приложению, то получаем всё те же недостатки God Object просто размазанные по сервисам - грязный, хрупкий, неповоротливый домен с запутанными связями.
Впрочем, это нормальный подход для небольших и не сложных систем, но всё же, заголовок статьи о других подходах.
"Скорее всего" - во первых потому что обычно сервис избыточен, поскольку большинство действий соответствуют одной сущности и идеально выражаются через её методы. Во вторых, сервис будет необходим при комплексных действиях, но не каждый такой случай потребует контроля особых инвариантов, сервис часто будет только работать с методами сущностей которые как и прежде контролируют свои инварианты.
Помещать в модель свои действия и контроль своих инвариантов предпочтительнее по причинам самодостаточности и удобства восприятия. Можно, наверное, сойтись на том что это вкусовщина и вынос всех действий в сервисы - просто другой подход к организации кода, но вот загрязнение этих доменных сервисов побочками, внесение их в домен на ровне с бизнес правилами предметной области - это совсем никуда не годиться, по крайней мере в контексте кейвордов из заголовка статьи.
Схему можно по разному нарисовать, часто изображают слои вложенными окружностями и тогда зависимость направлена снаружи - вглубь. Доменный слой - самый глубокий.
В статье на схеме зависимости отображены сплошными стрелками, что там нарисовано выше или ниже - смысловой нагрузки не имеет.
Репозитории находятся в инфраструктуре и реализуют интерфейсы определенные в домене - это отражает то, что реализация хранилища объекта домена зависит от домена и может существовать более одной реализации.
Вы забываете, что бизнес правила имеют деление. Есть бизнес правила относящиеся к предметной области, есть относящиеся к приложению.
Отправка письма при неком действии - это типичное бизнес правило уровня приложения, при разделении на слои контроль этого правила собственно и окажется в слое application.
Установка текущей даты при создании сущности - будет относится к уровню домена если нам необходимо гарантировать что у нас не должно быть возможным наличие сущности хранящей в себе дату отличающейся от фактической даты её создания. То есть, например, когда при создании сущности мы не можем передать эту дату на уровень домена извне.
Это именно что разные use cases и требования к ним, разрешаются на уровне приложения и никак не связаны с требованиям к модели предметной области. То есть в разных кейсах могут быть разные поля и требования к ним, но они в итоге должны привести к созданию модели удовлетворяющим глобальным требованиям. Если взять предыдущий пример, когда контроль даты создания - требование к модели, то какими бы небыли различными наборы полей в разных кейсах, дату создания задать через них не выйдет.
Инварианты должны гарантироваться на уровне домена, если сервис находится там, то технически он может взять на себя контроль какого то инварианта, но скорее всего для этого найдётся место получше.
DDD подразумевает моделирование предметной области, когда требование - часть предметной области, оно тоже попадает в модель. Так что всё же, если речь про DDD, то целостность и непротиворечивость, в той мере, в которой они выражаются в предметной области, нас при проектировании интересуют и не меньше чем сами данные.
Не дадут. Абсолютно бесполезное голосование. Большие цифры будут у более известных среди аудитории. Поправка на трафик ещё одна бесполезная процедура. Кроме того, у одной площадки могут быть как плохие так и хорошие курсы.
В общем, мусор на входе - мусор на выходе.
Как отмечено выше правильная методика - это дать возможность респондентам выбрать (или ввести самостоятельно) конкретный курс и дать ему оценку. Потом по этим данным можно было бы оценить и популярность и качество.
Принципиальной для обучения разницы между версиями нет. Изучать версии курсами не имеет смысла. Если курсы одного качества, проходите тот, что свежее, разницу между версиями посмотрите по обзорам изменений.
Интересная генерация. Сетку обучали на сете whataboutism?
А если брутфорс распределенный? А если используют средства обхода рекапчи? А если атакующий готов подождать успеха пару месяцев?