Зависит очень от совта продукта и прочего... Есть области где это Ок и работает отлично. У меня лично нет проблем хоть с масажистами в комманде. Когда девелоперы сделали свою работу написали юниттесты, тесты интеграции... и вы смотрите на это и вам все ещё надо ловить определныные проблемы качества более дорогими тестами с выделеными спецами фля это-го, то ради бога... Но не перепрыгивайте базовые вещи
Тема знакомая. Это с незапамятных времен так... Однажы довелось видеть комманду где из-запервернутой тестовой пирамиды вообще команда только и занималась починкой 2e2 тестов и медленно релизила что-то. Причем качество релизов никак не становилось лучше... Через 3-4 года их проект просто закрыли - ребята и девчата, все не могли проделиверить фичи с приемлимой скоростью.
Но продолжаю наблюдать игнор юнит тестов и прыжок сразу в мануальное прокликивание или автомазирование прокликивания... Это конечно тесно связано и с организационными причинами. Происходит в основном там, где нанимают таку ОТДЕЛьНУЮ роль как "тестировщик". И девелоперу становится "удобно". Веть за качество и за тесты у нас "тестировщик" отвечает... и сама организация нанимающая отдельных людей для это-го естественно это так и видит как норму. Не воспринимайте близко, но по моим наблюдениям, в восточной европе (аутсорсинг) прям это любимая тема..
Речь не о процессорном времени вообще. Это ерунда…
Разговор о том, что никто не деплоит монстра в конце пайпланайна. Вокруг монстра монолита разрастается целый проицесс. Начйионатся со соложтои мержа все вотну помоюку, планирование релизов, все это требует регресс тестов, планов по откату или наката баз данных, до отмашки от мэнеджмента при каждом деплойменте.
Вообще раздуть можно сильно а развитие системы полностю заблочнить. Наблюдаю не в порвой и не первое десятиление.
И да конечно я понимаю что архитектуры следуют организационным структурам, это все тоже не просто и не обойти.
Оставаясь в вашей терминологии:
микрокакашки когда они становятся критическими, куда проще выкинуть и заменить на менее пахучее, чем одну большую, размазаную на весь бизнес много лет назад.
Чувствуете разницу? ;)
Ну это утрированно.
Монолит может иметь очень хорошую врнутреннюю структуру и модульность, но всеравно будет оставаться монолитом со всеми вытекающими недостатками. Основной из них это то, что через CI/CD pipeline тоскается монстр и в него все интегрируется на каждый чих.
Отказ от Security Manager без какой-либо замены есть демонстрация убогости группы разработчиков JVM.
Серьезно? Прям так?
А может это ответ на реальность, в том что время когда деплоили все в один application server закончилось! и отлучно… Сегоднай так никто не строит.
А тем кому все это надо ещё к сожалению поддерживать, те так и так не переползут на 17 яву и даже на 9 тую врятли… они живут с совсем другими проблемами ;)
Domain Driven Design Тоже крайне интересно использованием этого подхода для реальных кейсов. Почему этот подход? Чем он лучше других?
А какие конкурирующие подходы к DDD вы можете привести?
Помоему их не так то и много.
Тоесть пытаясь ответить на ваш вопрос "почему"
1) Потому, что это хорошая идея моделирования не оторваная от предметной области а наоброто всецелостно от неё отталкивающаяся.
2) Дает ответы на разных уровнях абстракций. Стратегический дизайн, тактический дизайн…
3) Существует давно, опробован временем.
4) Получил ренесанс в эпоху облаков и микросервисов
Архитектор как командообразующий игрок.
Архитектор как командообразующий игрок. Вот это утверждение крайне спорное
А мне какраз это очень по духу. Именно так.
Сегодня это все очень взаимосвязанно. Роль архитекта это свазующее звено и в каждой огранизации будет свой уникальный набор.
Реашать задачи предметной области с помошью архитектуры это конечно интересно ;)
Но горазно эффективенне если ещё и есть кому это делать! Тоесь не в отрыви от людей и комманд которые это в жизнь воплащают а наоборот с полным погружением.
Наняли меня как-то архитектором, так я в первый год только комманды настраивал и процесс разработки "чинил" если хотите… Только потом можно было начинать что-то по архитектуре…
Есть разные уровни "запущености" ;)
Под мониторинг Prometheus, grafana а вот ELK я бы не стал. Прожерлив, капризен.
Если же толькио под логи, то ELK мне лично очень, и Logstash очень мощён, много чего можно с ним сделать… мы раньше доп. информацией логи снабжали и писали в спец. индексы и т.д. из логов много видели...
Но если хочется все в одном наверное сегодня надо смотреть в grafana стек, и там для логов есть вышеупомянутый loki. Я лично его ещё не видел в бою, но по документации очень правильная штука.
По смыслу это все же наоборот. О защите.
Если раньше можно было запрашивать ID девайса, то теперь апп дожена "умолять" пользователя и защита врубается на уровн опреционки.
Пусть меня поправят экспрты по IOS если я что-то упустил из виду.
Да интереснее наверно было бы сравнение с тулами. Я вот например на Flux2 второй кластер перевожу. Несмотря на то что ещё сыроват (и не GA даже) уже нравится и никаких проблем.
Вам повезло
Зависит очень от совта продукта и прочего...
Есть области где это Ок и работает отлично.
У меня лично нет проблем хоть с масажистами в комманде. Когда девелоперы сделали свою работу написали юниттесты, тесты интеграции... и вы смотрите на это и вам все ещё надо ловить определныные проблемы качества более дорогими тестами с выделеными спецами фля это-го, то ради бога... Но не перепрыгивайте базовые вещи
Тема знакомая. Это с незапамятных времен так...
Однажы довелось видеть комманду где из-запервернутой тестовой пирамиды вообще команда только и занималась починкой 2e2 тестов и медленно релизила что-то.
Причем качество релизов никак не становилось лучше... Через 3-4 года их проект просто закрыли - ребята и девчата, все не могли проделиверить фичи с приемлимой скоростью.
Но продолжаю наблюдать игнор юнит тестов и прыжок сразу в мануальное прокликивание или автомазирование прокликивания...
Это конечно тесно связано и с организационными причинами. Происходит в основном там, где нанимают таку ОТДЕЛьНУЮ роль как "тестировщик". И девелоперу становится "удобно". Веть за качество и за тесты у нас "тестировщик" отвечает... и сама организация нанимающая отдельных людей для это-го естественно это так и видит как норму.
Не воспринимайте близко, но по моим наблюдениям, в восточной европе (аутсорсинг) прям это любимая тема..
Ага ;) заставь дурака пайплан строить он и лоб и продакшн расшибет ;)
Речь не о процессорном времени вообще. Это ерунда…
Разговор о том, что никто не деплоит монстра в конце пайпланайна. Вокруг монстра монолита разрастается целый проицесс. Начйионатся со соложтои мержа все вотну помоюку, планирование релизов, все это требует регресс тестов, планов по откату или наката баз данных, до отмашки от мэнеджмента при каждом деплойменте.
Вообще раздуть можно сильно а развитие системы полностю заблочнить. Наблюдаю не в порвой и не первое десятиление.
И да конечно я понимаю что архитектуры следуют организационным структурам, это все тоже не просто и не обойти.
Ну конечно надо уметь готовить )
del
Незря! Очень круто! И дискуссия в каментах пока тоже хороша. ;) Спасибо за труд.
Оставаясь в вашей терминологии:
микрокакашки когда они становятся критическими, куда проще выкинуть и заменить на менее пахучее, чем одну большую, размазаную на весь бизнес много лет назад.
Чувствуете разницу? ;)
Ну это утрированно.
Монолит может иметь очень хорошую врнутреннюю структуру и модульность, но всеравно будет оставаться монолитом со всеми вытекающими недостатками. Основной из них это то, что через CI/CD pipeline тоскается монстр и в него все интегрируется на каждый чих.
Да, именно. У автора похоже "расспределенный монолит", деплой в продакшен раз в месяц и недопонятые преимущества микросервисов.
Вам легковесных потоков так нехватает? Или чего именно?
Везут (http://jdk.java.net/loom/), но какаую проблему это особо решает? интересно послушать.
Серьезно? Прям так?
А может это ответ на реальность, в том что время когда деплоили все в один application server закончилось! и отлучно… Сегоднай так никто не строит.
А тем кому все это надо ещё к сожалению поддерживать, те так и так не переползут на 17 яву и даже на 9 тую врятли… они живут с совсем другими проблемами ;)
А какие конкурирующие подходы к DDD вы можете привести?
Помоему их не так то и много.
Тоесть пытаясь ответить на ваш вопрос "почему"
1) Потому, что это хорошая идея моделирования не оторваная от предметной области а наоброто всецелостно от неё отталкивающаяся.
2) Дает ответы на разных уровнях абстракций. Стратегический дизайн, тактический дизайн…
3) Существует давно, опробован временем.
4) Получил ренесанс в эпоху облаков и микросервисов
Архитектор как командообразующий игрок.
И вся эта закрытая экосистема Эппл которая маркетологами ещё и как позитив выдается…
Вообщем по поводу Эппл полностью согласен с Павлом Дуровым. ;)
Уже бизнес класс в обычных перелетах обычно в 3 раза дороже. А первый класс в 10 и выше.
Так такие перелеты точно не для масс а для первых классов ;) Очень занятых людей ;)
Под мониторинг Prometheus, grafana а вот ELK я бы не стал. Прожерлив, капризен.
Если же толькио под логи, то ELK мне лично очень, и Logstash очень мощён, много чего можно с ним сделать… мы раньше доп. информацией логи снабжали и писали в спец. индексы и т.д. из логов много видели...
Но если хочется все в одном наверное сегодня надо смотреть в grafana стек, и там для логов есть вышеупомянутый loki. Я лично его ещё не видел в бою, но по документации очень правильная штука.
По смыслу это все же наоборот. О защите.
Если раньше можно было запрашивать ID девайса, то теперь апп дожена "умолять" пользователя и защита врубается на уровн опреционки.
Пусть меня поправят экспрты по IOS если я что-то упустил из виду.
Да интереснее наверно было бы сравнение с тулами. Я вот например на Flux2 второй кластер перевожу. Несмотря на то что ещё сыроват (и не GA даже) уже нравится и никаких проблем.