Это к @Greesha

Ну про 100500 ты загнул конечно. 3-5 хороших книг и нотация

Я проходила года четыре назад в Luxoft, в целом неплохой объемный взгляд дают

👍🙃😂🤣
100500 - это "достаточно для того, чтобы закрыть книгу и больше к ней никогда не возвращаться".

и так же скиллз для определения необходимого и достаточного набора диаграмм для описания систем. Но могу сказать, что из этого набора только sequence и заходят для разработки (сменила примерно 6 проектов за это время), и то в каждом проекте свое понимание зачем и почему нужна и как правильно рисовать)))

По хорошему, курс должен начинаться с этой птицы и слов: "Так значит, если у вас есть проблема проектировать систему и вы думаете, как это сделать, то сейчас я вам расскажу что, как и зачем надо рисовать. И кому вообще всё это нужно.".

Угу, от проекта к проекту выбираются разные инструменты проектирования.
Главное научиться понимать, где и что надо использовать.

Выношу я часть БД в другой компонент, рисую ERDG ASIS - TOBE дабы понимать, что и куда уйдёт и общаться с data quality специалистом и людьми из домена.
Или вот я иду к девопс, рисую компонентную диаграмму, чтобы был предметный разговор.
Ну или хочу я описать процесс взаимодействия между системами для программиста, то тут проще sequence сделать. Хотя вот для алкогоритмов проще BPMN порой.

Вот такие знания нужны + как это всё рисовать.

Чтобы не было диаграмм ради диаграмм.

Между системами - я обычно потоки данных рисую. Sequence хорошо описывает межсервисное взаимодействие. Тяжело приходится вам, везде экспертизу держать ( я обычно прошу принимать решения (или вносить предложения) экспертов по своей области, иначе как бы непонятно

Я последнее время прихожу с драфтом решения.
Понимая что надо сделать, легко можно разобраться как это сделать на высоком уровне.
Т.е. откуда взять данные, как их обработать или изменить.
Определяются источники данных, системы, оркестраторы (если нужны).
В рамках каждой системы определяются API, внутренние алгоритмы.
Лучше всего не привязываться к технологиям и обвешивать системы НФТ.
Вот с этим со всем, с кучей диаграмм я двигаю в архитектора/тимлида.
Раскуриваем это на 1-2 встречах, поправляем.
Потом согласовываем с большим кругом лиц, уточняем детали.
При необходимости разговариваю с доменными экспертами, прохожу с ними по алгоритмам, задаю каверзные вопросы.

Как итог - готовое решение, согласованное с бизнес-доменом, лидерами команд разработчиков и архитектором.

А лидеры и архитектор уже сами скажут, на джаве решение будет или на C#, на чём будет фронт, как это будет развёртываться, какая будет БД, какую технологию для очередей использовать.

Ну тут , мне кажется - все же лучше знать ограничения проектные до проработки какого то бы ни было решения. НФТ - это НФТ - а проект решения уже совсем не НФТ.

Об этом и речь, что ты предлагаешь драфт решения в рамках Ф/НФ требований на высоком уровне абстракции.
Т.е. люди понимают, что надо сделать и в каком качестве. Т.е. "как себя должна вести система".
А потом определяют технологии обработки, хранения, передачи данных и так далее.
И вот уже третий шаг - это работа с деталями алгоритмов, данных и уточнения.
И только после этого будет решение.

Мы на каждом шаге (уровне абстракции) уменьшаем риски проекта.

Т.е.
нет смысла говорить о вариантах хранения или передачи данных, когда не определены технологии.
нет смысла говорить о технологиях, когда непонятно, как должна себя вести система.

Ну, конечно ели проект не шаблонный.
С каждым годом у меня прослеживается тенденция к тому, что в проектах всё больше прослеживаются шаблоны.
И ты можешь не просто идти пошагово, а в некоторых случаях отдавать полное решение, зная возможности стека программистов в командах.

Это как раз граница между аналитиком и архитектором (не ну у арха есть и другие стороны, но с точки зрения решений - граница тут).

вот не люблю этих споров. Есть ли разница между поваром и управляющим ресторана? Да, это абсолютно разные профессии (роли). Но в шаверма баре возможно все)

Стеки технологические здесь конечно, при чем - но мы ведь про драфт оптимального решения, так? А здесь к оптимальности всегда свои требования, и на моем опыте - всегда лучше получается сделать драфт на мозговом штурме нескольких экспертов. Только и исключительно мое мнение, никому ничего не навязываю

тебе к Денису @denis_j_ivanov или Григорию Печёнкину. Лучше их в РФ точно не найдёшь