Угу, нет никаких возможностей одну структуру БД перевести в другую корректно и без явно указанных миграций. ORM тоже никак не избавляет от миграций (да и создавался для других вещей). Впрочем, в статье практически ничего полезного не сказано о миграциях.
Так-то и команды добавления колонки могут подвесить базу (если одновременно идет длинный отчет). А команда создания индекса опасна почти всегда. А кроме изменений структуры данных нужно еще обновить и сами данные и для этого нужно писать специальный движок (так как просто сделать update на большой базе не получится). И миграции надо тестировать (чтобы они боевую базу не убили), иногда откатывать (что почти всегда нетривиально), в процессе миграций поддерживать совместимость - и так далее и так далее.
Только SQL для этого, увы мало, все равно нужна внешняя обвязка, как минимум для идемпотентности миграций.
Компоненты - это не совсем шаблоны, это просто некоторая сущность, общая для всех диаграмм в проекте и изменяемая одновременно всюду. Обычно она является и "точкой входа" для отдельной диаграммы.
Не совсем так. В процессе обсуждения (proposed) ADR может редактироваться. Но потом он accepted, пока не станет deprecated. Если бы это было предложение, то называлось бы RFC или Proposal
Не, не буду обосновывать. Но именно так это читается носителем русского языка.
Выбор фреймворка или инструмент форматирования кода - это как раз очень небольшие части архитектуры. Впрочем, инструмент форматирования кода к архитектуре вообще отношения не имеет, заводить на это ADR достаточно странно
Ну, если не понимаете - то и ладно, вы же не архитектор, вам это не обязательно. Главное - не используйте свой перевод, так как он не соответствует понятию ADR
Архитектура ПО, разумеется. Хотя про переводоведение у меня тоже есть сомнения.
Э, какая приемная комиссия в обсуждении архитектуры? И нет, ADR никак не связан с принятием решения, только с документированием процесса принятия решения. Это же просто формат документа. Если уж буквально переводить, то "Запись про принятые решения касающиеся архитектуры"
Неа, "решение по архитектуре" - это "решение про всю архитектуру", а ADR - про небольшие части архитектуры системы, а не про всю. "Решение, касающееся архитектуры" - да, гораздо лучше. Никакого "выбора вариантов архитектуры" в ADR просто нет, документ не про "какие архитектуры можно выбрать", а про "как решить конкретную задачу-проблему, как-то касающуюся архитектуры". А "результат обсуждения архитектуры" - это перевод смысла ADR. Так как переводить без понимания предметной области - бесполезное занятие и ничего хорошего из этого не получится.
Очень интересный инструмент, спасибо. Для архитектурных задач не хватает еще нескольких вещей 1. "Библиотека компонент", изменения компонента отображаются всюду, где он используется. Ну, например, у нас внутренняя структура сервиса описывается в компоненте, там же можно указать его имя, часть атрибутов и используемую иконку. И если мы что-то поменяли в компоненте, то во всех диаграммах более высокого уровня - тоже все поменяется. 2. Типизация компонент и атрибутов к ним. Т.е. завожу тип "контейнер" и указываю у него стандартные атрибуты "объем памяти", "OS" etc И при содании - делаю уже готовый контейнер. 3. Ну и, на будущее, интеграция с разными wiki. Хотя бы в виде "SVG+ссылка на сайт".
Может быть стоит попробовать найти крупную компанию, где есть спрос на подобный инструментарий и договорится о совместном развитии. Или сделаться стартапером, написать бизнес-план и попробовать пару миллионов баксов получить на развитие )
Нет там "вариантов архитектуры", так как ADR не про "выбор варианта", а про решение одного конкретного tradeoff или про обсуждение одного конкретного изменения. Поэтому предложенный в статье перевод - ужасен, так как полностью теряет реальный смысл фразы. Можно перевести как "решения по поводу архитектуры" или даже "Результат обсуждения архитектуры". Или вообще не переводить, так как зачем?
Хм, а почему kafka сложнее развертывать и под нее сложнее разрабатывать? Скорее уж проще, там гораздо понятнее и логика работы и гарантии, да и настроек поменьше.
Ну, саги появились давно, но нормальных реализаций, увы, нет. А реализация саги разработчиком, который использует YDB как монолит - еще хуже, нежели использование YDB как монолит ) Реализация корректных и надежных саг мало отличима от ручной реализации 2PC (
Если у вас остаток клиента на какое-то время ушел в минус, а вы не банк, а НКО - то ничего страшного не случится, просто лицензию отнимут и бизнес закроют. Вообще, сценариев с жесткими требованиями к целостности - достаточно много.
А зачем вообще использовать тактический DDD? Он вообще крайне громоздкий и неэффективный и довольно плохо описанный.
Из чисто технических мелочей; 1) Вообще "саги" в современном понимании не обязательно предполагают компенсации. Да и "позвать человека, чтобы исправил" - это, формально, тоже компенсация. 2) Tempora лучше использовать проведения линейной транзакции, без откатов. Вообще нужно строить систему так, чтобы не было понятие "вызов компенсации" и "откат транзакции", только "повтор". Как ни странно, почти во всех случаях это возможно. 3) Как только у вас появляется распределенная система и требуется хоть какая-то целостность - нужно реализовывать механизмы реконсиляции. Для МСА по DDD - это особенно необходимо из-за огромного объема дублирования информации.
И да, в IT есть две настоящие проблемы. DDD помогает с одной за счет другой )
"Как система должна работать" - это и есть проектирование. И это может делать только человек, погруженный в реализацию системы (разработчик, архитектор, техлид и т.п.). Это не имеет никакого отношения к анализу.
Связующее звено между бизнесом и разработкой (на IT-службой, это вообще из другой оперы) называются продакт-менеджерами.
Опять проблемы с терминологией. То, что в статье называют бизнес-аналитиком - как раз функции системного аналитика в большинстве компаний. То, что назвали "системным аналитиком" - функции техлида или разработчика внедрения. Про функции бизнес-аналитика в статье вообще ни слова не сказано.
Хочу напомнить, что аналитик - не занимается проектированием и разработкой, это задачи для другой роли. В статье смешали задачи решения проблем заказчика, сбора требований, проектирования и реализации. Это разные активности, которые могут очень разными способами распределяться по команде, но "как" - это всегда задачи разработчика, а не аналитика.
А в чем разница рынка и ниши? Как формально отличить рынок профессиональных фотоаппаратов от рынка фотоаппаратов от рынка камер и фотоаппаратов от рынка устройств с камерой и даже от рынка техологичных игрушек? Это все рынки, пересекающиеся, вложенные друг в друга - но рынки.
Ниша - это про часть рынка с низкой конкуренцией. Про указанные рынки нельзя сказать, что там низкая конкуренция. Впрочем, разница между рынком, сегментом и нишей - весьма сомнительная и зависит от целей рассмотрения.
Хм, глубоко не нырял. Но в некоторых камерах шумодав работает даже на RAW, увы, особенно на высоких ISO. Хотя формально - да, просто значения, снятые с матрицы. Производительность встроенного в камеру процессора - один из признаков, отличающих старшие камеры в линейке - и там довольно много работы. Хотя, конечно, в основном это про генерацию jpeg, но не только.
Угу, нет никаких возможностей одну структуру БД перевести в другую корректно и без явно указанных миграций. ORM тоже никак не избавляет от миграций (да и создавался для других вещей).
Впрочем, в статье практически ничего полезного не сказано о миграциях.
Так-то и команды добавления колонки могут подвесить базу (если одновременно идет длинный отчет). А команда создания индекса опасна почти всегда. А кроме изменений структуры данных нужно еще обновить и сами данные и для этого нужно писать специальный движок (так как просто сделать update на большой базе не получится).
И миграции надо тестировать (чтобы они боевую базу не убили), иногда откатывать (что почти всегда нетривиально), в процессе миграций поддерживать совместимость - и так далее и так далее.
Только SQL для этого, увы мало, все равно нужна внешняя обвязка, как минимум для идемпотентности миграций.
Компоненты - это не совсем шаблоны, это просто некоторая сущность, общая для всех диаграмм в проекте и изменяемая одновременно всюду. Обычно она является и "точкой входа" для отдельной диаграммы.
Не совсем так. В процессе обсуждения (proposed) ADR может редактироваться. Но потом он accepted, пока не станет deprecated. Если бы это было предложение, то называлось бы RFC или Proposal
Не, не буду обосновывать. Но именно так это читается носителем русского языка.
Выбор фреймворка или инструмент форматирования кода - это как раз очень небольшие части архитектуры. Впрочем, инструмент форматирования кода к архитектуре вообще отношения не имеет, заводить на это ADR достаточно странно
Ну, если не понимаете - то и ладно, вы же не архитектор, вам это не обязательно. Главное - не используйте свой перевод, так как он не соответствует понятию ADR
Архитектура ПО, разумеется. Хотя про переводоведение у меня тоже есть сомнения.
Э, какая приемная комиссия в обсуждении архитектуры? И нет, ADR никак не связан с принятием решения, только с документированием процесса принятия решения.
Это же просто формат документа. Если уж буквально переводить, то "Запись про принятые решения касающиеся архитектуры"
Неа, "решение по архитектуре" - это "решение про всю архитектуру", а ADR - про небольшие части архитектуры системы, а не про всю. "Решение, касающееся архитектуры" - да, гораздо лучше.
Никакого "выбора вариантов архитектуры" в ADR просто нет, документ не про "какие архитектуры можно выбрать", а про "как решить конкретную задачу-проблему, как-то касающуюся архитектуры".
А "результат обсуждения архитектуры" - это перевод смысла ADR. Так как переводить без понимания предметной области - бесполезное занятие и ничего хорошего из этого не получится.
Очень интересный инструмент, спасибо.
Для архитектурных задач не хватает еще нескольких вещей
1. "Библиотека компонент", изменения компонента отображаются всюду, где он используется.
Ну, например, у нас внутренняя структура сервиса описывается в компоненте, там же можно указать его имя, часть атрибутов и используемую иконку. И если мы что-то поменяли в компоненте, то во всех диаграммах более высокого уровня - тоже все поменяется.
2. Типизация компонент и атрибутов к ним.
Т.е. завожу тип "контейнер" и указываю у него стандартные атрибуты "объем памяти", "OS" etc
И при содании - делаю уже готовый контейнер.
3. Ну и, на будущее, интеграция с разными wiki. Хотя бы в виде "SVG+ссылка на сайт".
Может быть стоит попробовать найти крупную компанию, где есть спрос на подобный инструментарий и договорится о совместном развитии. Или сделаться стартапером, написать бизнес-план и попробовать пару миллионов баксов получить на развитие )
Нет там "вариантов архитектуры", так как ADR не про "выбор варианта", а про решение одного конкретного tradeoff или про обсуждение одного конкретного изменения.
Поэтому предложенный в статье перевод - ужасен, так как полностью теряет реальный смысл фразы.
Можно перевести как "решения по поводу архитектуры" или даже "Результат обсуждения архитектуры". Или вообще не переводить, так как зачем?
Хм, а что прощает кролик такого, что не прощает кафка?
Ну и сейчас уже, подозреваю, не осталось энтерпрайза, где остался win.
Как раз обычно все на linux или вообще в облаках.
Хм, а почему kafka сложнее развертывать и под нее сложнее разрабатывать? Скорее уж проще, там гораздо понятнее и логика работы и гарантии, да и настроек поменьше.
Ну, саги появились давно, но нормальных реализаций, увы, нет. А реализация саги разработчиком, который использует YDB как монолит - еще хуже, нежели использование YDB как монолит )
Реализация корректных и надежных саг мало отличима от ручной реализации 2PC (
Если у вас остаток клиента на какое-то время ушел в минус, а вы не банк, а НКО - то ничего страшного не случится, просто лицензию отнимут и бизнес закроют.
Вообще, сценариев с жесткими требованиями к целостности - достаточно много.
А зачем вообще использовать тактический DDD? Он вообще крайне громоздкий и неэффективный и довольно плохо описанный.
Из чисто технических мелочей;
1) Вообще "саги" в современном понимании не обязательно предполагают компенсации. Да и "позвать человека, чтобы исправил" - это, формально, тоже компенсация.
2) Tempora лучше использовать проведения линейной транзакции, без откатов. Вообще нужно строить систему так, чтобы не было понятие "вызов компенсации" и "откат транзакции", только "повтор". Как ни странно, почти во всех случаях это возможно.
3) Как только у вас появляется распределенная система и требуется хоть какая-то целостность - нужно реализовывать механизмы реконсиляции. Для МСА по DDD - это особенно необходимо из-за огромного объема дублирования информации.
И да, в IT есть две настоящие проблемы. DDD помогает с одной за счет другой )
"Как система должна работать" - это и есть проектирование. И это может делать только человек, погруженный в реализацию системы (разработчик, архитектор, техлид и т.п.).
Это не имеет никакого отношения к анализу.
Связующее звено между бизнесом и разработкой (на IT-службой, это вообще из другой оперы) называются продакт-менеджерами.
Опять проблемы с терминологией. То, что в статье называют бизнес-аналитиком - как раз функции системного аналитика в большинстве компаний. То, что назвали "системным аналитиком" - функции техлида или разработчика внедрения. Про функции бизнес-аналитика в статье вообще ни слова не сказано.
Хочу напомнить, что аналитик - не занимается проектированием и разработкой, это задачи для другой роли.
В статье смешали задачи решения проблем заказчика, сбора требований, проектирования и реализации. Это разные активности, которые могут очень разными способами распределяться по команде, но "как" - это всегда задачи разработчика, а не аналитика.
Ой, да, ошибся, спасибо!
Нет, с 01.03.2022 временный порядок вывоза наличности, не больше 10k$ на человека.
Управление фокусом глазом, кстати, у Никона тоже было. Но выкинули, как неудобное.
Кто в 90х сделал первым - уже не помню...
А в чем разница рынка и ниши? Как формально отличить рынок профессиональных фотоаппаратов от рынка фотоаппаратов от рынка камер и фотоаппаратов от рынка устройств с камерой и даже от рынка техологичных игрушек?
Это все рынки, пересекающиеся, вложенные друг в друга - но рынки.
Ниша - это про часть рынка с низкой конкуренцией. Про указанные рынки нельзя сказать, что там низкая конкуренция.
Впрочем, разница между рынком, сегментом и нишей - весьма сомнительная и зависит от целей рассмотрения.
Хм, глубоко не нырял. Но в некоторых камерах шумодав работает даже на RAW, увы, особенно на высоких ISO. Хотя формально - да, просто значения, снятые с матрицы.
Производительность встроенного в камеру процессора - один из признаков, отличающих старшие камеры в линейке - и там довольно много работы. Хотя, конечно, в основном это про генерацию jpeg, но не только.