Если еще по инфраструктуре, то DevOps и big data литература

Принял
Благодарю

в чате вакансий по го даже джунов периодически ищут, но чаще всего это из россии вакансии

спрашивал у своих опытных в  NodeJS знакомых. Рекомендуют Go. На него обычно переписывают разросшиеся проекты

Тире есть то что следует читать в первую очередь:

1. Domain Driven Design (Vaughn Vernon)

2 — Enterprise Integration Patterns (Gregor Hohpe, Bobby Wolf)

3. Software system architecture (Nick Rozanski, Eoin Woods)

4. Building Evolutionary Architectures (Neal Ford, Rebecca Parsons & Patrick Kua)

5 — Function and Reactive Domain Modeling (Debasish Ghosh)

6 — Practical Microservices Architectural Patterns (Binidias Christudas)

7. Архитектура предприятия (Андрей Коротков)

8. Architecting for Scale (Lee Atchison)

9 — Архитектура корпоративных программных приложения (Мартин Фаулер)

10 — Clean Architecture (Robert C. Martin)

11. Enterprise Angular (Manfred Steyer)

12. Enterprise Angular Monorepo Patterns (Victor Savkin, Nitin Vericherla)

13 — Применение UML 2.0 и шаблонов проектирования (Крэг Ларман)

14. Микросервисы. Паттерны разработки и рефакторинга (Крис Ричардсон)

15. Monolith to Microservices. Evolutionary Patterns to Transform Your Monolith (Sam Newman)

16. Object-Orinted Software Construction (Bertrand Meyer)

17. Pattern-orinted software Architecture (Douglas Schmidt, Michael Stal, Hans Rohnert and Frank Buschmann)

18. Practical Enteprise Data Lake Insights (Saurbah Gupta, Venkata Giri)

19. Распределенные системы. Паттерны проектирования (Брендан Бернс)

20. Reactive messaging patterns with the Actor Model (Vaughn Vernon)

21 — Software Architecture in practice (Len Bass, Paul Clements, Rick Kazman)

22. Discovering requirements (Ian Alexander, Ljerka Beus-Dukic)

нихрена себе
от души

Когда система достигает десятков тысяч строк кода, то все эти GOFы, GRASPы, SOLIDы и прочие штучки до лампочки становятся

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

😃

единственный паттерн, который нужно соблюдать - это KISS

👍 код надо писать а не гофами, бобами, драями, граспами всякими  голову забивать. Будь проще и работа за тобой потянется, больше спагетти, больше работы. Больше работы меньше дидиди и пр. мозговыноса. 🤣

больше работы - больше денег

Во-во. И жизнь проще

Вон сверху адепт твоего подхода уже мне отписал что это все не важно до 1000 строк кода, а это значит что когда ты декомпозируешь архитектурно всю систему как минимум на модули в которых до тысяче строк кода, то значит читаем правило номер один! ☝️

Неее - декомпозиция от лукавого. Даёшь transaction script и все норм. )

Та там ваще без разницы чем... Всё-равно система скатывается в альфа-эквивалентность...

да как вы такие переходы то строите, не пойму
или если мы рассматриваем выхлопную, простите, трубу, нам не важен весь остальной автомобиль?

О выхлопной трубе можно мыслить дивергентно, выхлопная труба как например размер: от автомобиля, заводская, станционная, генераторная, мопедная, бричковая, танковая и т.д. т.п.

нам не важен её размер, материал и точки крепления, если мы рассматриваем её отдельно от ТС
однако же на практике почему-то эти критерии важны

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

но если ты выделил в системе модуль, который делает то же самое, что скрипт, уже нельзя рассматривать этот модуль отдельно от остальной системе
банально потому что живут они вместе, и развиваться будут вместе

Так все эти гофи, граспы и тд несут больше рекомендательный характер нежели утвердительный. Если слепо следовать им то да, скорее всего от них толку не будет, даже наоборот.  Это же опыт людей которые поделись своим опытом для конкретных проблем. На каждом проекте все индивидуально и тебе решать что и как использовать. А если у  тебя есть знания и опыт других людей, тебе проще принять/написать свое правильное решения, которое будет оптимальным для конкретной задачи