Это вы просто знаете что функция использует 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, то целостность и непротиворечивость, в той мере, в которой они выражаются в предметной области, нас при проектировании интересуют и не меньше чем сами данные.
На масштабе эти результаты дадут ответ на вопрос о самых неудачных курсах
Не дадут. Абсолютно бесполезное голосование. Большие цифры будут у более известных среди аудитории. Поправка на трафик ещё одна бесполезная процедура. Кроме того, у одной площадки могут быть как плохие так и хорошие курсы.
В общем, мусор на входе - мусор на выходе.
Как отмечено выше правильная методика - это дать возможность респондентам выбрать (или ввести самостоятельно) конкретный курс и дать ему оценку. Потом по этим данным можно было бы оценить и популярность и качество.
Принципиальной для обучения разницы между версиями нет. Изучать версии курсами не имеет смысла. Если курсы одного качества, проходите тот, что свежее, разницу между версиями посмотрите по обзорам изменений.
Связность - это о внутренних связях модуля, из контекста (и статьи и ваших сообщений) ясно, что речь идёт не об этом. К тому же в отличии от связанности её обычно стараются держать высокой.
В Event-driven добавляется 3й элемент - очередь сообщений, что наоборот, усложняет схему работы
Так упрощается или усложняется?
Но сам процесс "стал знать меньше" - это не потому, что на событийную модель перешли, а потому что рефакторинг/переделки были, которые и уменьшили связность модулей, чтобы взаимодействие лучше на событийную модель "ложилось".
При неком событии в модуле А, необходимо некое действие в модуле Б. Это бизнес требование, а не зависимость в терминах архитектуры, то есть сам факт такого требования не увеличивает связанность А (связность тем более, ну тут автор просто термин перепутал).
Далее, при реализации требования мы добавляем в А вызов Б. Теперь А зависит от Б - то есть связанность выросла. Точно таким же образом мы поступаем с В, Г, Д и тд - связанность растёт и растет.
Теперь возвращаемся к исходному тезису
Такой подход позволяет нам сильно уменьшить связанность нашей системы и упростить её поддержку и расширяемость.
Вместо паутины зависимостей между модулями у нас появляется одна зависимость от интерфейса шины событий в каждом, где это необходимо, другими словами: такой подход позволяет нам сильно уменьшить связанность нашей системы.
Автор не заявляет что это единственный подход. А то, что для внесения изменений в архитектуру необходим рефакторинг - самоочевидно.
При распространенности такой практики в проекте заводить этот тикет можно сразу в dev/null ибо никто о нём более никогда не вспомнит. Уж лучше коммент чиркануть к методу о возможности его оптимизации и примечание в доке о сценарии использования, тогда хотя бы есть шанс что на это обратят внимание, когда захотят использовать его не по назначению или таки столкнутся непосредственно с проблемой его быстродействия.
Правила переходов состояний - логика приложения, а не системы хранения данных. В конечном итоге окажется, что во первых приложение всё равно должно гарантировать соблюдение этих правил на своей стороне, а бд в свою очередь не гарантирует выполнение других/новых реализация которых на её уровне может оказаться делом затруднительным/невозможным/накладывающим ограничения.
Не говоря уже о зависимости от sql хранилища, удобства тестировании и тд.
Обычно просто дозирующий насос используется (или трубки вентури), ничего изобретать не требуется. Шприц - не серьезно, маточный раствор чаще всего подмешивается в пропорции 1 к 100, он уже сильно концентрированный и расход у него на такой небольшой объем из статьи будет до литра в день. (upd забыл что тут замкнутый цикл, в нем меньше расход, да)
Так может тогда не делать полностью замкнутый цикл? Открутили раствор N раз и слили. Без постоянного анализа состава замкнутый цикл не сработает, постоянно перекос профиля будет, а анализы такие будут стоить намного дороже слитого раствора. Даже в незамкнутых системах удобрения составляют не особо значительную часть расходов, копейки на фоне электричества.
«Хардкорная инженерия — это не 10 000 строк кода после того, как вы выпили 4 стакана Red Bull, а выяснение того, как заменить эти 10 000 строк на 10, после того как выпили бокал шампанского», — пояснил Хотц.
Это вы просто знаете что функция использует 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?
А если брутфорс распределенный? А если используют средства обхода рекапчи? А если атакующий готов подождать успеха пару месяцев?
Идёт программист по офису, видит - кубикл, сел в него и сгорел.
Связность - это о внутренних связях модуля, из контекста (и статьи и ваших сообщений) ясно, что речь идёт не об этом. К тому же в отличии от связанности её обычно стараются держать высокой.
Что может быть проще прямого вызова?
Так упрощается или усложняется?
При неком событии в модуле А, необходимо некое действие в модуле Б. Это бизнес требование, а не зависимость в терминах архитектуры, то есть сам факт такого требования не увеличивает связанность А (связность тем более, ну тут автор просто термин перепутал).
Далее, при реализации требования мы добавляем в А вызов Б. Теперь А зависит от Б - то есть связанность выросла. Точно таким же образом мы поступаем с В, Г, Д и тд - связанность растёт и растет.
Теперь возвращаемся к исходному тезису
Вместо паутины зависимостей между модулями у нас появляется одна зависимость от интерфейса шины событий в каждом, где это необходимо, другими словами: такой подход позволяет нам сильно уменьшить связанность нашей системы.
Автор не заявляет что это единственный подход. А то, что для внесения изменений в архитектуру необходим рефакторинг - самоочевидно.
При распространенности такой практики в проекте заводить этот тикет можно сразу в dev/null ибо никто о нём более никогда не вспомнит. Уж лучше коммент чиркануть к методу о возможности его оптимизации и примечание в доке о сценарии использования, тогда хотя бы есть шанс что на это обратят внимание, когда захотят использовать его не по назначению или таки столкнутся непосредственно с проблемой его быстродействия.
Правила переходов состояний - логика приложения, а не системы хранения данных. В конечном итоге окажется, что во первых приложение всё равно должно гарантировать соблюдение этих правил на своей стороне, а бд в свою очередь не гарантирует выполнение других/новых реализация которых на её уровне может оказаться делом затруднительным/невозможным/накладывающим ограничения.
Не говоря уже о зависимости от sql хранилища, удобства тестировании и тд.
Вы б ещё про торты и торты спросили...
Обычно просто дозирующий насос используется (или трубки вентури), ничего изобретать не требуется. Шприц - не серьезно, маточный раствор чаще всего подмешивается в пропорции 1 к 100, он уже сильно концентрированный и расход у него на такой небольшой объем из статьи будет до литра в день. (upd забыл что тут замкнутый цикл, в нем меньше расход, да)
Так может тогда не делать полностью замкнутый цикл? Открутили раствор N раз и слили. Без постоянного анализа состава замкнутый цикл не сработает, постоянно перекос профиля будет, а анализы такие будут стоить намного дороже слитого раствора. Даже в незамкнутых системах удобрения составляют не особо значительную часть расходов, копейки на фоне электричества.
Ну так.. этож лид.. ЗП лида должна быть длинней сеньёрской.
«Хардкорная инженерия — это не 10 000 строк кода после того, как вы выпили 4 стакана Red Bull, а выяснение того, как заменить эти 10 000 строк на 10, после того как выпили бокал шампанского», — пояснил Хотц.