Виктор П.

Вам нужен паттерн Outbox, посмотрите
Смысл в том, что при записи какой-то сущности в базе мы открываем транзакцию и пишем в две таблицы, в основную и в outbox. Транзакция гарантирует сохранение события. Затем паблишим в кафку из аутбокса какой-то джобой

Привет,
Тут тема такая, основная фишка в том, что нет чёткого определения, что такое архитектор. У кого-то в компании аналогичная должность может называться и руководитель проекта, у кого-то тимлид, у кого-то архитектор. И соль в том, что любой вышестоящий начальник вкладывает в эту должность абсолютно разный набор функциональных обязанностей.
Что могу посоветовать, надеюсь, это станет ответом на вопрос. Есть проект на гитхабе роадмап тимлида. Там есть прикольные картинки и, собственно, что вам нужно сделать:
Первое, принять, что теперь за всё отвечаете вы лично. То есть, вроде как отдел кадров подбирает персонал, но всё равно именно вы набираете под себя команду и вы лично за неё несёте ответственность. Если вам задают вопрос по продукту - типа, что это за кнопка добавилась - ответ "я не знаю, это без меня добавили" неприемлем. Если вылетел баг на проде - то обосрались лично вы.
Второе, после принятия ответственности, необходимо пройтись по всему дереву-снежинке и отметить, в каких областях у вас хорошо, а в каких провал. И из первого пункта тут вытекают разного рода решения, например планёрки (или скрам) для того, чтобы именно вы были в курсе, кто чем занимается. Код ревью и внедрение ci/cd, чтобы не вылезали баги на проде и так далее. Вот тут уже, если вы не разбираетесь в какой-то узкой области, можно взять какой-то курс. То есть, нет такого общего "курсы для архитекторов" - там вам воды в уши нальют, есть роадмап, по которому вам надо идти. И есть узкоспециализированные курсы под каждую область, где у вас провал, вот так.
Третье, необходим баланс, вам нельзя замкнуть все процессы на себя. Есть правило автобуса (что будет с проектом, если вы не выйдете на работу?). Это очень полезное правило - процессы должны быть выстроены таким образом, чтобы вы могли спокойно уйти в отпуск и вам никто не звонил. Это тоже очень важная составляющая организации работы. Вообще авралов не должно быть, только штатные ситуации. Если вы решите поменять работу, чтобы не пришлось в последний день собирать документацию с айпишниками, логинами/паролями участвующих в вашем проекте виртуальных машин, так как должна вестись своевременная документация по ресурсам и используемому ПО. Вроде как про это никто заранее не говорил, но это ваша обязанность и вы отвечаете за такие вещи лично (повторюсь ещё раз о важности делегирования и отсутствия переработок)

Добрый день,
Процесс, который вы описываете, называется рефакторинг. Советую по данной теме лёгкое чтиво refactoring.guru
Так же, существуют общие советы, так называемые принципы, вот первая ссылка в гугле, поверхностно, но должно быть понятно.
Отвечая на ваш вопрос, дублирования кода не должно быть. Делаете один метод. Потом, если, вдруг, появится разветвление, то в этой фукнции остаётся общий код и появляются две другие, в которых будет разный код

Пробегите бегло по паттернам, возможно, найдете, что вам подходит https://refactoring.guru/ru/design-patterns/behavi...

https://metanit.com/web/angular2/1.1.php

О, я так и думал, что будет много советов читать книги по архитектуре. С ними такая подстава, на уровне джуна ты не будешь понимать, о чём вообще говорится в этих книгах. Или будешь понимать, и такой, даа, автор жжёт, правильные вещи говорит, а вот что делать с этим дальше - не в курсе, так как практики нет. А вот когда дорастёшь до какого-нибудь ведущего, тогда будешь перечитывать еще раз с мыслью "аа, так вот что он имел в виду". И вот именно из-за этого, многие на начальном этапе не осиливают такие книги, поэтому, если есть лишнее время, можно почитать.
Что нужно делать: идёшь в энтерпрайз. Да или просто в компанию, которая пилит 1-4 продукта с разными командами. В команде должно быть по нескольку человек. И постоянно достаёшь более опытных разрабов с вопросами почему сделано именно так. Плюс должно быть код ревью, чтобы более опытные тебе постоянно указывали на твои ошибки, что вот так делать не надо.
Через год меняешь контору, но чтоб тоже сложные проекты были и были команды, и так же достаёшь вопросами почему сделано так, а не иначе.
Тогда и придёт понимание как делать удобнее и правильнее. Вот тогда и можешь почитать книги по архитектуре, чтобы еще больше пришло познание.
Избегай контор, в которых будешь работать один или двое, это болото, которое не даст тебе такого мощного проф развития.
Касательно написания более понятного и чистого кода, этот вопрос не относится к архитектуре. Это всё тоже придёт с практикой и с код ревью. Как вариант, чтобы усилить, можно посмотреть паттерны, вот есть крутой сайтец с приятными картинками, лёгкое чтиво (естественно, достаточно того, что в открытом доступе):
https://refactoring.guru/

Посмотрите в сторону SOA - сервис ориентированная архитектура. На основе wcf. У сервиса (на любом языке) есть интерфейс, на его основе генерируются контракты (xml), которые подключаются в другие языки и получаются вызывы методы сторонних сервисов.

"на чем умеешь или на чем удобнее" - самый верный ответ ))
php, ruby, c#, даже упомянутый node.js - это языки высокого уровня, что означает, что любая вещь, сделанная на одном языке может быть так же сделана на другом языке. Это к упоминаниям о словах "масштабируемость" и "стабильность" - они не привязаны к языку.
Если у вас нет опыта, то первое, куда нужно смотреть - как организовать работу, например, если специалистов на php больше, чем на RoR, то нужно брать php, так как будет легче найти сотрудников и зарплаты у них будут ниже.
Второе, опять же к снижению бюджета, если вы найдёте специалиста на .net стеке, он, несомненно, сможет вам сделать масштабируемое и отказоустойчивое решение, но по итогу его работы окажется, что лицензии для вин. сервера и для базы данных стоят больших денег.
Если вам нет разницы, берите подешевле )

Хорошая программа Sap Power Designer - попробуй поработать с ней, ну и посмотри под неё курсы

Как на первом курсе учили - не знаете, как программировать - рисуйте блок-схему. Шутка, конечно, кроме универа ни разу блок-схему и не рисовал.
Если серьёзно, занимаюсь веб-разработкой и иногда бывают сложные специфические задачи, прям "сломай мозг", тогда я использую моделирование баз данных. В институте это был продукт ErWin, но я обхожусь бумагой и ручкой. Смысл в том, чтобы уложить задачу в модель данных, очень структурирует мысли, и, когда все нужные данные улеглись на бумаге, обычно становится всё понятно, и сразу ясно, что и как надо делать. Мне вполне хватает