Мне вот в последнее время более важно, чтобы условный мессенджер из трех букв не сливал мои фотки и адреса серверов (тоже трехбуквенных). При условии наличия этой функциональности в ОС - уж с кривым пуском как нибудь бы прожил.
Так ведь многие еще и наивно верят, что их поделку купят за 100500 денег. То, что ее точно так же может сгенерировать обладатель этих денег - во внимание не принимается.
Так я же не против использования нейронок. Сам пользуюсь. Я имел в виду, что как-то опасно запускать скрипт, в котором не понимаешь ни слова. Именно так я понял Ваш комментарий.
Я давно сбросил написание всяких общеизвестных штук на нейронки, но по принципу: вот тебе интерфейс, напиши реализацию используя такие то библиотеки. Да и то приходится перепроверять результат.
Я пару раз применял в подобной ситуации такой подход: возвращал с сервера сразу html и менял содержимое элемента-контейнера. Но такой способ, конечно, для совсем уж простых случаев, типа отправки формы.
- Вы очень хорошо выполняете работу, пора вам прибавить... - Денег к зарплате? - Нет, объема работы. - Но ведь с ростом нагрузки качество работы падает. - Тогда лишим премии.
Менеджер - это подмножество сотрудников. Я не знаю, как понятнее то еще написать. Нет такой профессии - сотрудник. Есть разные там секретари, уборщики, начальники отдела, и т.д. и т.п.
Рабо́тник, или сотру́дник — субъект трудового права, физическое лицо, работающее по трудовому договору у работодателя и получающее за это заработную плату.
Нет, все правильно. С чего вдруг менеджер не сотрудник? Я бы отпал на этапе понять задачу
Это скорее был пример, что не стоит делать архитектуру вида "спагетти". Даже в одной БД имеет смысл разделение на модули. Транзакции, затрагивающие 50 таблиц тоже ведь так себе решение.
Я имел в виду, возражения в духе "бизнесу нужно чтобы одновременно" - через DDD не решаются или решаются неудобно. Но по факту, оказывается что "бизнес" задержка в "одновременности" в пару секунд - вполне устраивает. И в итоге DDD вполне работает и облегчает разработку. Агрегат сохраняется вместе с событиями (тот самый outbox) в одной транзакции в свои таблички, а после этого события расползаются по связанным агрегатам и системам, производя свои изменения неявно для первого агрегата. Система стает слабо связанной и более устойчивой к сбоям.
Я за свою жизнь ни разу не встречал проекта, которому бы хватило одной БД для всего. Абсолютно на всех местах работы системы вроде как и декларировались самодостаточными, но по факту зависели от других. И в итоге постоянно решались проблемы синхронизации данных между ними. Обычно костылями. Так что я давно уже не верю, что можно "транзакцией в БД" решить все проблемы. А уж в нынешнее время, когда микросервисы пихают всюду, и где это оправдано, и просто чтобы быть "как все" - можно смело забывать эти преимущества и привыкать работать по новому)
А еще вместо табличек (реляционной БД) может быть вообще что угодно. Хоть текстовые файлы определенного формата. И ничего при смене технологии хранения менять не придется, кроме реализации "репозитория". И да, в серьезных проектах - иногда приходится менять систему хранения на более подходящую. И в итоге часть агрегатов живет в postgresql, часть в elastic, а часть вообще в другой системе с доступом по rest api. А в слое домена все однотипное.
Бизнесу нужно, чтобы при создании «Заказа» одновременно создавался «Платеж», резервировался «Товар» на складе и создавалась «Задача» в колл-центре.
Постоянно слышу от противников/сомневающихся в DDD подобные примеры, что он, дескать, не работает в реальном мире. Да, наверное, где-то и есть такой бизнес, где абсолютно все реализуется в одной системе и можно решать задачи одной транзакцией.
Только вот в реальном мире на складе одна система, платежами заведует другая, колл-центром третья, половина из них - куплены как готовые решения (и часто без штатных механизмов интеграции). Ну, и как в таких условиях будете решать эту задачу? Поможет тут DDD или нет?
Мне вот в последнее время более важно, чтобы условный мессенджер из трех букв не сливал мои фотки и адреса серверов (тоже трехбуквенных). При условии наличия этой функциональности в ОС - уж с кривым пуском как нибудь бы прожил.
Так ведь многие еще и наивно верят, что их поделку купят за 100500 денег. То, что ее точно так же может сгенерировать обладатель этих денег - во внимание не принимается.
Так я же не против использования нейронок. Сам пользуюсь. Я имел в виду, что как-то опасно запускать скрипт, в котором не понимаешь ни слова. Именно так я понял Ваш комментарий.
Я давно сбросил написание всяких общеизвестных штук на нейронки, но по принципу: вот тебе интерфейс, напиши реализацию используя такие то библиотеки. Да и то приходится перепроверять результат.
Я пару раз применял в подобной ситуации такой подход: возвращал с сервера сразу html и менял содержимое элемента-контейнера. Но такой способ, конечно, для совсем уж простых случаев, типа отправки формы.
А если бы этот скрипт не сделал свою работу, а безвозвратно удалил ваши тысячи виртуалок?
Вот, кстати, хороший анекдот к теме:
Кто понял жизнь, тот не спешит )
А вообще, лучше купить лицензию на 1С зарплата и кадры и не мучать мозг. Дешевле для бизнеса выйдет. Я бы на месте собеседуемого так предложил
Менеджер - это подмножество сотрудников. Я не знаю, как понятнее то еще написать. Нет такой профессии - сотрудник. Есть разные там секретари, уборщики, начальники отдела, и т.д. и т.п.
Даже в википедию залез.
Нет, все правильно. С чего вдруг менеджер не сотрудник? Я бы отпал на этапе понять задачу
Аналогично, пришел со временем к такой же архитектуре
Ну, в общем то да. DDD просто снижает когнитивную сложность.
Это скорее был пример, что не стоит делать архитектуру вида "спагетти". Даже в одной БД имеет смысл разделение на модули. Транзакции, затрагивающие 50 таблиц тоже ведь так себе решение.
Я имел в виду, возражения в духе "бизнесу нужно чтобы одновременно" - через DDD не решаются или решаются неудобно. Но по факту, оказывается что "бизнес" задержка в "одновременности" в пару секунд - вполне устраивает. И в итоге DDD вполне работает и облегчает разработку. Агрегат сохраняется вместе с событиями (тот самый outbox) в одной транзакции в свои таблички, а после этого события расползаются по связанным агрегатам и системам, производя свои изменения неявно для первого агрегата. Система стает слабо связанной и более устойчивой к сбоям.
Я за свою жизнь ни разу не встречал проекта, которому бы хватило одной БД для всего. Абсолютно на всех местах работы системы вроде как и декларировались самодостаточными, но по факту зависели от других. И в итоге постоянно решались проблемы синхронизации данных между ними. Обычно костылями. Так что я давно уже не верю, что можно "транзакцией в БД" решить все проблемы. А уж в нынешнее время, когда микросервисы пихают всюду, и где это оправдано, и просто чтобы быть "как все" - можно смело забывать эти преимущества и привыкать работать по новому)
А еще вместо табличек (реляционной БД) может быть вообще что угодно. Хоть текстовые файлы определенного формата. И ничего при смене технологии хранения менять не придется, кроме реализации "репозитория". И да, в серьезных проектах - иногда приходится менять систему хранения на более подходящую. И в итоге часть агрегатов живет в postgresql, часть в elastic, а часть вообще в другой системе с доступом по rest api. А в слое домена все однотипное.
Постоянно слышу от противников/сомневающихся в DDD подобные примеры, что он, дескать, не работает в реальном мире. Да, наверное, где-то и есть такой бизнес, где абсолютно все реализуется в одной системе и можно решать задачи одной транзакцией.
Только вот в реальном мире на складе одна система, платежами заведует другая, колл-центром третья, половина из них - куплены как готовые решения (и часто без штатных механизмов интеграции). Ну, и как в таких условиях будете решать эту задачу? Поможет тут DDD или нет?