не совсем понял, в вашем "реальном мире" кафка (шина сообщений) заменяет Монгу (СУБД)? А бизнесу, у которого целостность была "из коробки" с 1980-х годов, вы теперь предлагаете "целостность вам нужна в ограниченной области"?
В идеальном мире при любой архитектуре нет неявных зависимостей. Там, например, на каждый чих меняется версия API, а микробаза данных у каждого микросервиса своя. Жаль, автор не стал описывать стоимость поддержки N баз данных и распределенных транзакций.
При опечатке птичка вылетает на первом же тесте. Встроенный сиквел умеет проверять синтаксис во время компиляции. Наверное, опечататься при заполнении и отсылки очередного джейсона чем-то приниципиально отличается в лучшую сторону.
Расширение темы называется флудом. Если уж расширять, так с музыкой! Возьмем SMP на 1000 ядер и запустим на каждом по строчке. Попробуйте так с циклом.
Библиотеки и фреймворки (неплохо было бы коротко указать разницу) ни хороши, ни плохи сами по себе. Это просто инструменты, позволяющие опираться на сторонние наработки. Выбор оптимального для данной задачи, проекта, продукта инструментария - нетривиальная задача, но ошибки на этом этапе будут стоить дорого в перспективе.
Вера в LLM несколько наивна, но объяснима: любой красиво и правильно говорящий человек априори кажется умным и понимающим суть того, что он высказывает.
Переписывание со старого шила на новое мыло касается в основном небольших и относительно простых приложений. Остальные системы живут десятилетиями и "умирают" разве что из-за прекращения поддержки/ухода разработчиков.
Насчет одной строчки я иронизирую, конечно. "Гибкая" разработка, если под этим понимать аджайлы и прочий стыд-и-скрам не решают проблему, а переносят её на плечи заказчика (что не так уж и плохо). Попытки действительно решить задачу были в 1990-е, спиральные методики. Но для них нужен высокий уровень организации у самого подрядчика. В общем, все безрадостно пока.
не совсем понял, в вашем "реальном мире" кафка (шина сообщений) заменяет Монгу (СУБД)? А бизнесу, у которого целостность была "из коробки" с 1980-х годов, вы теперь предлагаете "целостность вам нужна в ограниченной области"?
Вопросы получились риторическими.
https://blog.arbinada.com/ru/category/01704-crud.html
Проблема когерентности кэшей перпендикулярна сервисности или монолитности архитектуры, она начинается с N=2
В идеальном мире при любой архитектуре нет неявных зависимостей. Там, например, на каждый чих меняется версия API, а микробаза данных у каждого микросервиса своя. Жаль, автор не стал описывать стоимость поддержки N баз данных и распределенных транзакций.
Тесно перекликается с написанной 4 года назад "Блеск и нищета микросервисов"
Про CRUD-ошлёпство и Митрофанушек: ttps://blog.arbinada.com/ru/category/01704-crud.html
... а DDD, в свою очередь, подойдет для систем симуляции, в отличие от информационных систем, где модель 100% анемичная по определению
https://blog.arbinada.com/ru/category/01705-clean-architecture.html
При опечатке птичка вылетает на первом же тесте. Встроенный сиквел умеет проверять синтаксис во время компиляции. Наверное, опечататься при заполнении и отсылки очередного джейсона чем-то приниципиально отличается в лучшую сторону.
Некрокомментарий, но со стороны своего опыта автоматизации ИС должен вас поддержать :)
https://www.linkedin.com/posts/sta_чистая-архитектура-и-domain-driven-design-activity-7110941995493122049-61iC
Если это была реплика ко мне, то цитата чужая.
Расширение темы называется флудом. Если уж расширять, так с музыкой! Возьмем SMP на 1000 ядер и запустим на каждом по строчке. Попробуйте так с циклом.
Проверьте оба варианта, если есть какие-то сомнения. Только компилируйте без оптимизации.
Ну, а по какой причине компилятор может раскрыть цикл? Неужели из-за большей производительности кода в цикле?
Даже первокурснику известно, что
int sum = 0;for (int i = 0; i < 1000; ++i) {
sum += f(i);
}
выполняется медленнее, чем
int sum = 0;sum += f(0);
sum += f(1);
...
sum += f(999);
А если функцию раскрыть, то еще быстрее.
Следут ли из этого, что нужно пользоваться наиболее быстро исполняемым кодом?
Споры о накладных расходах из-за таблицы виртуальных методов велись 30 лет назад. Наверное, имеет смысл просто поднять архивы и привести выводы :)
"Смешались в кучу кони, люди..."
Библиотеки и фреймворки (неплохо было бы коротко указать разницу) ни хороши, ни плохи сами по себе. Это просто инструменты, позволяющие опираться на сторонние наработки. Выбор оптимального для данной задачи, проекта, продукта инструментария - нетривиальная задача, но ошибки на этом этапе будут стоить дорого в перспективе.
Вера в LLM несколько наивна, но объяснима: любой красиво и правильно говорящий человек априори кажется умным и понимающим суть того, что он высказывает.
На выбор:
- Design Develop Destroy (выкрасить и выбросить)
- Davai Davai Davai (Go, go, go !)
- Damn Dumb Domain (программист-бухгалтер)
В правильной организации разработчики делятся на core platform и functional modules.
И весь этот горький катаклизм... микрокомпонентный хайп уже был минимум дважды. И дважды обходился дорого.
Блеск и нищета микросервисов
Переписывание со старого шила на новое мыло касается в основном небольших и относительно простых приложений. Остальные системы живут десятилетиями и "умирают" разве что из-за прекращения поддержки/ухода разработчиков.
Насчет одной строчки я иронизирую, конечно. "Гибкая" разработка, если под этим понимать аджайлы и прочий стыд-и-скрам не решают проблему, а переносят её на плечи заказчика (что не так уж и плохо). Попытки действительно решить задачу были в 1990-е, спиральные методики. Но для них нужен высокий уровень организации у самого подрядчика. В общем, все безрадостно пока.
Итого: в ТЗ можно обойтись одной строчкой: "Система должна удовлетворять заказчика"
"Зачем учить географию, если есть извозчики?" (с) "Недоросль"