Кстати, в прошлом веке была традиция реально хороших эпиграфов для IT-литературы. Но сейчас это практически умерло, насколько я могу судить...

Agile Architecture: «Mobilis in mobile»

Хочу поделиться, если кто не видел. Тут ребята пишут бесплатную книгу https://threedots.tech/, она ещё в процессе, по реализации архитектурных паттернов в GoLang.

У меня особое предвзято отношение что на GoLang пишут то, что завтра выбросят вместе с банкротством проекта, но ребята меняют эту точку зрения)

Сейчас там есть про CQRC, DDD и Clean Architecture.

Всегда с некоторым недоумением относился к идее реализации такого рода вещей именно на языке X, ведь такие вещи от яп не особо зависят.

Разве что мб проще потом тянуть к себе, если тоже прогаете на X

c чего Golang выбросят ? Нишу он себе нашел

Конечно, это общие идеи, не зависящее от платформы вовсе. Тем не менее, на молодых языках сам путь обучения идёт в стиле "не думай об архитектуре, не думай о донных, бери библиотеку реализации и меси BL прям с реализаций и жёсткими связями". Тут ребята первый раз именно в Go начали писать что и в молодых языках для Agile мира надо сначала думать.

Я не про язык именно.

Это отношение для меня подписано некоторой статистикой, но я бы не хотел это обсуждать, потому что это субъективное мнение и я не хочу донести его всем как единую истину.

пока ни один язык не обанкротился. Даже Кобол живет в темных местах

В общем я о том, что для молодых языков, на которых часто пишут MVP за сжатые сроки, так же нужно показывать примеры что и там нужно думать об архитектуре. И нельзя потом с Quickstart Guide в том же стиле писать приложение с ЖЦ в 10 лет например.

Ещё раз, там не про язык посыл

так про паттерны написали выше, они инвариантны по отношению к языку. Язык может упрощать или усложнять их реализацию, но это дело техники

На это я тоже ответил.

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

Если бы Assembler появился сегодня, то маркетинг бы и из него сделал "делай, не думай", с курсами "стань Senior Assembler за неделю" и набором библиотек/фреймфорков где можно месить бизнес-логику с реализацией)

Примеры архитектурных паттернов на конкретном языке мне кажутся нужными. Чтобы кто начал с быстрого старта заметил что и у них есть идеи как писать правильно. А может через подход в своём конкретном ЯП заинтересовался архитектурой в целом.

тут проблема в обучении программированию и языкам. Когда фокус на структуру, концепции , общие вещи - то менять языки не проблема. Но сейчас кажется по другому учат, отсюда и толпа "спецов" с курсов всяких.  Если не уметь выделять общее в языках, то и с паттернами проблемы будут. Причем на всех языках...

Прочитал про бест прэктис, про натягивание процессов на коробки и пр

Вот 4 круглых колеса для седана - бест прэктис. Конечно новый автопроизводитель может попробовать поставить 3 квадратных, и это точно будет его выделять, но вряд ли такое авто будет иметь хоть какой-то успех

За счёт чего может выйти на рынок новый автопроизводитель? За счёт новой бизнес-модели, частью которой является УЦП

Также отдельными частями бизнес-модели являются, среди прочего, партнёры, ресурсы, и ПРОЦЕССЫ. Они могут быть уникальными

К чему это

И бест прэктис и уникальность вполне могут уживаться

А itil странное сделал, переименовав бест в гуд. 4 круглых колёса на седане, это бест на сегодня. Бест прэктис существует и имеет право на жизнь

Если мне нужно развернуть, допустим, отказоустойчивый кластер Kafka или Cassandra, в первую очередь обращусь к best practices

Что касается коробок

Коробки хороши в непрофильных и вспомогательных/инфраструктурных частях бизнеса, которые хорошо автоматизированы и которые (это индикатор) можно (хотя бы теоретически) отдать на аутсорс

Например, бухгалтерия

В других моментах может быть важен TTM и важно иметь экспертизу у себя.

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

Часто это компании, которые удачно первыми заняли определённую нишу (оказались в нужное время в нужном месте)

Ну и всегда нужно помнить, что процессы противоречат креативу (см Адизеса)

Если нужен креатив и творчество, то нормально и даже необходимо иметь бардак (в разумных масштабах) и странно иметь процессы (см опять же Адизеса)

Если пошутить

Маркетологов не нужно лечить от алкогольной зависимости и разгонять их свингерские коммуны.

Жить богемной жизнью для творческих людей нормально (но не обязательно)

Вот Мунка вылечили, и каков результат?))