Есть вечная двойственность в продвинутом обучении программированию...

С одной стороны, мы можем сперва мощно прокачивать свою базу (базу в смысле Старкрафта/Варкрафта :), а затем выполнять молниеносный успешный раш вообще на любую проблему. Например прокачавшись как следует в профильной математике, в том же функциональном комбинировании -- развив пресловутое сильное рациональное мышление -- мы будем видеть любые повседневные архитектурные схемы как задачки для третьего класса, которые решаются просто в режиме непрерывного набора идеально работающего кода (Make Illegal States Unrepresentable) даже без особого думания на медленном мышлении S2 по Канеману. Главный минус -- для этого требуется существенное время, и имеет ли ради этого жертвовать несколькими годами карьеры, вопрос открытый.

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

Противоположное Computer Science сегодня -- это когда надо хорошо знать System Design, но тоже больше на уровне "зазубрить шаблоны" и скомбинировать десяток "квадратиков" на диаграмме (и хорошо ещё, если это C4). Уметь красиво рассказать на собесе "как написать свой нетфликс", для чего достаточно изучить три гайда (но технические знания конечно должны быть на уровне). Главный минус -- в результате имеем совсем узенькое системное мышление, крайне хрупкое понимание, сразу ломается на новом проекте, где на 15% другой стек, даже CRUD фиг перенесёшь. Но зато быстро.

=

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

повысить производственное мастерство x10..x100, не прокачивая скиллы.

База в cs конечно нужна, но тут вполне достаточно 3-4 первых треков второй части Лаборатории. Более теоретические темки буду постепенно добавлять однозначно (языки вроде Lean4 всё же тяжеловато ребятам осваивать, если в хороших университетах не обучались... хотя вот в SMT-солверы с моего гайда въезжают только так практически все :), но пожалуй

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

И вот тут стоит добавить два уровня пояснения (опционально!): первый - это какой в них смысл с точки зрения функционального проектирования, что за функциональные паттерны, и второй - а как вообще эта механика устроена детально/формально - на теорем-прувере вроде Lean, или в гомотопической теории.

...Потому что в 98% реальных проектов, даже на тысячу таблиц, программист мало когда использует 3-5 паттернов на одну фичу (да и то редко когда сознательно; как известно, в тысяче строк любого кода найдётся хотя бы одна монада, но кто об этом знает :).

7-9 -- уже сложный случай (порт/адаптер, оркестрация...), и как правило тут паттерны выражены аннотациями/конфигом, а не "ручным" кодом.

Ну например, этот ваш CRUD будет таким паттерном:

controller/endpoint -> mapper (dto, entity) -> use case (service) -> repo -> db

Сквозной путь запроса/кейса -- максимум 10–12 логических шагов (включая нутро фреймворка!). Переходов между bounded contexts при этом -- три максимум, хопов DI-зависимостей -- пять максимум. и т.д.
на эту тему в СильныхИдеях на днях выложу материал
"Проектирование "снизу вверх" через рефакторинг (и при чём тут зависимости)"

Вообще, если регулярно получаете >7 ручных слоёв на типовую фичу -- упрощайте модель, ищите подходящую библиотеку, пилите DSL...

...Ладно, спалю базу: хорошая архитектура -- это не больше слоёв/глубже комбинаций паттернов, а меньше "случайной" сложности при сохранении явных инвариантов. Держим сквозной путь ≤10-12 и автоматизируем всё, что не домен.

"Идеальность" архитектуры не связана с глубиной вложенности паттернов. Она растет, как считается в программной инженерии, пропорционально ясности сценариев по BDD, инкапсуляции и low coupling (хотя я писал целый сериал, почему low coupling -- это больше абстракция, чем практика).

Ставьте на чистую доменную модель с явными границами, конвейеры политик и Functional Core/Imperative Shell (максимум логики в чистом ядре, "эффекты" на границах, причём "эффектный" слой должен быть как можно тоньше).

+ Рекомендую capability-ориентированный дизайн: это когда глупенький пишет тупой CRUD...

user.setStatus("ACTIVE");
userRepository.save(user);
// да, но с какой целью??

...а умненький явно выражает бизнес-намерение:

userActivationService.activateUser(userId);

=

Далее выявляем порты -- интерфейсы на границе домена, которая таким образом задаётся явно. Затем определяем соответствующую алгебру -- формальную сигнатуру операций на этой границе (что домен требует от внешнего мира? БД, REST, брокер?).

Алгебра в данном контексте -- это абстрактный набор операций предметной области (подписание платежа, чтение корзины, генерация UUID), заданных как чистая спецификация (а уж под каким эффектом это исполняется -- не важно). Мой гайд по абстрактным типам данных в ООП в помощь, а в ФП это что-то типа Tagless Final/Free Algebras (что тоже разбираю в соответствующем гайде :).

Ну и далее "интерпретатор" реализует алгебру поверх конкретных эффектов/технологий (DB/HTTP/...)...

=

Учимся по BDD распознавать (неявные) вариации и ограничения в ТЗ и маппить их на паттерны. По моим оценкам, таких паттернов около 50, ну может под сотню. Готовой теории, которая бы их охватывала и систематизировала, у меня нету, поэтому сперва их надо сформулировать и классифицировать, затем добавить функциональное описание, затем формальное, а потом и сама теория родится, полагаю, естественно и легко.

Когда разные высокие чины говорят, что "AI, по сути, может выполнять работу джуниора", это признак полной некомпетентности в ИТ. Эти люди, видимо, никогда не работали с джуниорами.

Ценность младшего разработчика составляет, наверное, около 20% в виде написанного им кода, а 80% -- это аванс на ближайшие год-два, когда он уже не будет младшим. Всё, что тут может AI -- это лишь немножко заменить первые 20%...

Все сегодня стремятся внедрить модные фишки AI -- агенты, RAG, серверы MCP, инструментальные решения...

За шумихой скрывается мрачная правда: большинство команд идут на невидимый (и невероятный по потенциальной катастрофичности) риск.

Баги просачиваются через тесты и логи. Выдача LLM-ок не поддаётся проверке. Зависимости и контейнеры формируют цепочки мутных последствий, которые никогда не придут человеку в голову. Архитектура превращается в набор костылей вокруг "магии" чёрного ящика. Внешние сервисы получают неконтролируемый доступ к ядру данных, а стаи агентов самостоятельно принимают решения, о которых вы узнаёте постфактум, когда уже всё рухнуло безвозвратно. Идемпотентность и ACID-транзакции размываются в угоду "гибкости". Цепочки вызовов не имеют единой точки отказа -- но и не имеют единого состояния истины, и существуют словно в сферическом вакууме.

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

"Хотя… скоро, на мой взгляд, вообще никаких тем не будет. Грядут крайне тяжелые времена и коснутся они всех, так или иначе. Впереди ждут долгие и многие годы, наполненные ужасом и унынием. Не думайте, что я какой-то паникер или специально смуту развожу. Вовсе нет. Просто делюсь внутренними ощущениями. И кажется мне, что ничего хорошего будущее не предвещает.
Да и когда в последний раз был хорошо и спокойно?"
-- Мэд

😁

...Вообще, мэйнстрим -- это абсолютный абсурд. Буквально на каждом собеседовании куда угодно кандидатов могут долго и упорно пытать по базе SOLID, причём неформально: техлид искренне убеждён, что их-то многослойная/многоуровневая система полностью этому соответствует, и поэтому так важно знать SOLID и паттерны проектирования.

При том, что их система -- это когда фронтенд зависит от бизнес-логики (через тот же REST), а бизнес-логика в свою очередь зависит от базы данных "под ней" (то есть слой UI максимально удалён от слоя работы с данными, между ними есть промежуточный доменный слой).

Ну, а разве у вас по-другому? :)

Да, но это есть прямое нарушение DIP:

Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

А у вас логика домена (концентрат всех ваших абстракций, вся ваша система типов) зависит от логики доступа к данным.

Ну и какой тут солид-шмолид...

Думайте.

Смешное: Nearly All Binary Searches and Mergesorts are Broken

Даже в легендарных "Жемчужинах программирования" Бентли, которыми я когда-то зачитывался, найдена ошибка, причём сама по себе детская - арифметическое переполнение. В восьмидесятые автор просто не предполагал, что на год потребуется четыре цифры могут быть массивы размером в миллиард элементов. И многие десятилетия эта бага расползалась по всему миру.
Кстати, кто проходил мой курс "Незримые механизмы логики", мы там разбираем на примерах базу доказательства корректности кода (триплы Хоара...), попробуйте этот код верифицировать, чтобы таких ошибок не было.

И это из проверенного учебника, который AI считает весьма достоверным. А сколько забагованного кода AI тащит в твой прод из кривых проектов с гитхаба? (риторическое)

Никакое архитекторство тебя не спасёт, когда в твоём проде низкоуровневый говнокод :)

Никуда в конечном итоге будет не деться от формальной верификации...

.

Облако драгоценностей за неделю.

Приватный клуб:

...В следующий раз, когда вы подумаете о создании "служебного" статического класса XYZUtils, спросите себя: может ли это быть объект моего домена?

Для донов-начинающих:

Делайте больше сложных дел — это один из лучших способов усвоить важные уроки о своей карьере, да и о жизни...

75%+ взрослых людей от 25 лет могли бы выбрать любой интеллектуальный/инженерный навык и пробиться в топ-10% в мире, просто работая исключительно над этим каждый день в течение двух-трёх лет. И это с нуля...

Ни Оксфорд ни Гарвард ни МГУ никаким "реальным проектам" и скорейшему применению информатики "на практике" принципиально не учат, наоборот: на протяжении всех 4-6 лет даётся всё больше теории computer science и математики...

Для донов-неначинающих:

Почему вам не получается расти?..

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

(все старые материалы для донов постепенно сгорают)

=

Первые сериалы из существенно переработанных и улучшенных материалов СильныхИдей (по сути три книги) доступны на бусти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-25
4. Гайд Вайб-проектирование

🚀

=

Новые материалы для ментатов Лаборатории.

Важно: уточнены правила занятий п.10.1.2.8: каждые календарные полгода вы должны (бесплатно) перепроходить три первых курса АСД, а затем дополнительные курсы АСД...

В СильныеИдеи добавлен материал "125) Проектирование "снизу вверх" через рефакторинг (и при чём тут зависимости)"
На первый взгляд эти два понятия выглядят прямо противоположными.
Проектирование -- это высокоуровневая бизнес-логика, абстракции, модели домена, семантика... Рефакторинг -- это чисто механическая схема работы с кодом по форме, не затрагивая реализацию.
Но разработка крупных систем столь сложная тема, что лучше всего её рассматривать через квантовую призму -- всё запутано со всем :)

В курс карьеры добавлен 116-й материал "Плохой ли вы сотрудник?".
Одно время я списывал такую двойственность (что решил посвятить свое время чему-то ещё, кроме компании-работодателя) на то, что работал не в тех немногих избранных компаниях мечты. Ну или как минимум не в той сфере. Но вот что случилось, когда я в них поработал...

💪🏻

Мы здесь, потому что это трудно.
it's a privilege to do things that are hard.

=

"ЛаМПовое": стратегема Agile-Манифеста, vim, "Диспетчер", внешние API, 60% неудачных сборок CI, "Алиса в Стране чудес невыученных уроков". ...

"...В [...] сходил на техническое собеседование. В целом прошло неплохо, но не хватило уверенности в решении задач на кодирование. В целом все как обычно. Видимо, надо целенаправленно усиливать это направление. Первая вакансия за долгое время, где жалею, что не прошел. По крайней мере по описанию вакансии там должно было быть интересно.
Была еще третья компания. Сами написали, давно такого не было. Хотели опыт в процессинге/эквайринге, которого у меня нет, поэтому дальше разговора с HR'ом не пошло.
Спросили бы отказоустойчивый кластер Kafka настроить, тут я с закрытыми глазами...

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

Мы же это ещё на первом курсе АСД проходили!!1 )))

+ с тех пор я добавил в каждый курс АСД десятки новых задачек посложнее, и теперь периодически всем ментатам надо будет перепроходить эти курсы (а также дополнительные, которые я делал по лекциям ШАД), дабы быть готовым к лайв-кодингу 💪🏻

АСД -- вечная база для собесов!

Интеллект не может быть обобщён в виде 5-шагового видеоролика продолжительностью в 1 минуту, поэтому, если вы здесь не для того, чтобы регулярно изучать что-то сложное для ума, пожалуйста, найдите свой быстрый дофамин где-нибудь в другом месте.

Если же вы будете упорствовать в правильных темках, этот блог радикально изменит направление вашей жизни.

Смысл мема => R⁴ -- группа вращений квадрата (циклическая группа порядка 4). Поразительно, но Филдсовская медаль была вручена за Exotic Smooth Structures, бесконечным числом коих обладает только R4. Для любого другого пространства Rn при n != 4 существует ровно одна гладкая структура (только один "естественный" способ определить на нём понятие гладкости и производной).

Exotic Smooth Structures -- это такие чрезвычайно странные пространства, которые гомеоморфны R4 (т.е. с т.зр. топологии это то же самое), но не диффеоморфны ему (с т.зр. гладкого исчисления это совершенно другие объекты, в них нельзя гладко преобразовать одну систему координат в другую). Выглядят одинаково, но плавной трансформации между ними нету.

Кто изучал матан, знает, что анализ в R4 особенно сложный.

В 3D-графике точки часто представляют в однородных координатах (вектор в R4 [x,y,z,w]).

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

p.s. Математики подправили: "R^4 - это не группа вращений квадрата и не циклическая группа порядка 4. Группа вращений квадрата - это частный случай группы диэддра, она конечна, у нее порядок 8."
Конечная группа вращений квадрата — это C4. А R⁴ — это четырёхмерное топологическое многообразие, гомеоморфное стандартному четырёхмерному евклидову пространству.
Exotic differentiable structures on R^4

Думаю, уже в этом десятилетии интеллектуальную элиту в топовых универах будут учить Программированию совершенно по другому, потому что AI-говнокодинг уничтожил классическое программирование более чем полностью, взамен предложив эрзац: нечто гораздо более дешёвое и более быстрое (на первый взгляд, если забыть о техдолге) и, соответственно, гораздо более хрупкое.

База программной инженерии - делаем максимально качественно, чтобы было как можно меньше ошибок, и в дальнейшем проект сопровождать и развивать будет легко, просто и недорого - с явлением AI в мэйнстриме забыта навсегда :) Нахерачим агентами быстро-быстро тонны кривейшего и совершенно непонятного кода, в котором ни один разработчик не разберётся без поллитра и за год, кое-как натянем прод на тестовую сову, отчитаемся об успехе, а дальше гори всё огнём. Сбылись самые влажные мечты каждого айти-менеджера :) Не то что через год что будет с проектом, да пофиг, что поломается на следующей неделе.

Ну и в целом, чем запутаннее и "нечеловечнее" код, чем сложнее его развивать, чем сложнее подключать к нему сторонних белковых, тем меньше шансов, что уволят конкретно тебя :)

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

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

ООП -- действительно интуитивно понятная (массам:) проекция фундаментального механизма нашего мышления (и очень поверхностная), да только засада в том, что категории, более-менее подходящие для социального выживания, оказываются весьма слабым инструментом в проектировании крупных и сложных формальных систем.

Тут хорошо бы сперва купить у меня побольше курсов пройти "как понять в programming in small всё", где разбираем исторические корни ООП и его место в десятках других подходов, затем мой гайд по объектной вычислительной модели, после чего, надеюсь, будет хорошее понимание и концептуальной структуры ООП, и более сильных подходов.
(Какой ещё полиморфизм в ООП? Смешно. Так, детский лепет...)

Потом трек по ООАП, где получаем наивную формализацию ООП через абстрактные типы данных, включая понимание концепции модулей. Но делаем задания по реальному "объектному" кодингу только на чистом С++ (потому что множественное наследование и дружественные функции), а потом на его темплейтах.

Ну и наконец изучаем взрослую формализацию ООП в теорем-прувере Lean (или на моей реализации HoTT).

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

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

Таким образом, вопрос не в том, разрушит ли AI наш мозг.

Сермяжный вопрос заключается в следующем:

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

.

Облако драгоценностей за неделю.

Приватный клуб:

Сегодня я вижу следы ЖПТ везде: в пулл-риквестах, в документации, даже в архитектурах. Но вот в чём дело: вам должно быть всё равно, что сказал искусственный интеллект. Вам должно быть важно, что вы сами думаете...

В 98% случаев техлиды, которых периодически консультирую, спрашивают одно и то же:
Как нам ускорить выкат новых фич? Как нам делать меньше ошибок?
Возникает соблазн стараться двигаться быстрее или быть более осторожным при написании кода. Но, как говорил Кент Бек, это похоже на попытку заставить машину ехать быстрее, используя переключатель скоростей...


Для донов-начинающих:

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

Лучшее время, чтобы взяться за программирование по-взрослому -- это ...


Для донов-неначинающих:

Давайте поговорим о том, о чем никто другой разработчикам не говорит...
Твой невидимый потолок.
Это может быть около 200 тысяч рублей. Или 300. Максимум 450.
Именно здесь большинство миддлов и сеньоров тихо уходят в отставку...

Хуже неудачи только медленный провал — такой, когда вы постоянно заняты, но никогда по-настоящему не продвигаетесь вперёд.
Другими словами... долгое, нескончаемое измельчение рутинными задачками. Стирание в пыль.
Каждый день начинается с благих намерений… а затем заканчивается подавленностью и аналитическим параличом...

Продолжаю выкладывать для донов материалы СильныхИдей — доступны моим курсантам, но тут расширенные и дополненные версии.
60. Как справляться с краевыми случаями
База по пониманию объектно-ориентированного проектирования.

(все старые материалы для донов постепенно сгорают)

=

Первые сериалы из существенно переработанных и улучшенных материалов СильныхИдей (по сути три книги) доступны на бусти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-25
4. Гайд Вайб-проектирование
+ Скоро выйдет моя новая книга "Software Design с акцентом на Programming in Large", и цены на это всё вырастут.

...Я бы мог массово продавать гайды, курсы, книги, но за этим всем нету живых людей, это просто деньги, поэтому это мне не очень интересно. А видеть, как растут 🚀 ребята, с которыми постоянно общаешься, вот это кайф ❤️


=

Новые материалы для ментатов Лаборатории.

В СильныеИдеи добавлен материал "126) Что такое корректность программы?"
В большинстве случаев в реальном мире корректность означает "отсутствие ошибок". Ну, за исключением того, что "ошибки" -- это не очень чёткая категория. Ошибка -- это лишь то, что заставляет кого-то сказать: "Это работает неправильно, там ошибка". Слишком медленная работа -- это ошибка, опечатка -- это ошибка, функция посчитала "не совсем то" -- это ошибка, и т.д. "Правильная работа" -- это немного расплывчато...

В курс карьеры добавлен 117-й материал "Твоя карьера -- это бесконечная игра".
Для начала признаем, что рынок сейчас непростой. Большинство разработчиков имеют высокую квалификацию, и компании выберут лучшего из множества кандидатов. Это не тот рынок, где за новой работой быстро следует повышение. Но это не значит, что вы должны хвататься за первую попавшуюся работу...


💪🏻

Мы здесь, потому что это трудно.
it's a privilege to do things that are hard.

=

Ну и наконец бета-тест "Матриц Хакера (МаХ)" закончен (был только один баг, и тот я знал заранее, просто неохота было самому ловить :), и все желающие могут поиграть (десктоп-версия для windows).

С праздником, Казанская! ❤️🙏😇

Что такое обучение?

Группе А даётся урок по арифметическим последовательностям, а затем задаются вопросы по их применению (например, постоянная скорость движения).

Группе Б даётся урок по постоянной скорости движения, а затем задаются вопросы по её обобщению (арифметические последовательности).

Какая группа справилась лучше (риторическое)?

Я тоже очень люблю юньку!!1 ❤️

Помню, лет 15 назад, когда в Unity добавилась поддержка андроида, я под вдохновение наклепал десяток мобильных игр, по советским настолкам в основном, а одна получилась особо душевная: тетрис с SKI-комбинаторами :)

Потом в Delphi появилась кроссплатформная разработка (винда, мак, линукс, андроид), но жутко кривая, а потом и сама эта замечательная платформа заглохла к сожалению (причём - классика - исключительно из-за ошибок эффективных менеджеров, как и в 98% всех провальных/проваленных ИТ-проектов).

Unity же продолжал успешно развиваться, хотя и тут менеджеры предпринимали не одну попытку его утопить :) чего стоит одна эпопея с платными подписками. Честно говоря, странно даже, что он ещё жив :) громоздкий движок сам по себе, куча багов медленное развитие -- и это на фоне активных анрила и годота.

Но, реально, юнька -- это такой народный движок, любимый массами несмотря ни на что! ❤️

Поучительная история, как один стажёр Wu Xiaoyun весь айтишный мэйнстрим уничтожил: 2x Performance, $300k Savings: A Case Study in Rewriting a Critical Service in Rust

Взяли его в ТикТок, где он взял да переписал гошный сервис на раст, получил огромный выигрыш в производительности, и вдобавок его сервис ежегодно экономит 300,000 долларов за облачный хостинг.

Все эти понтовые хайлоад-конференции, "специализированные" супер-пупер языки "заточенные под highload", толстенные учебники-кабанчики, многочасовые стримы про сложнейшие архитектуры и system design -- пузыристость и бессмысленность этого всего, буквально на грани инфоцыганства, наглядно продемонстрировал всему миру один умный молодой парнишка. Потому что решает прежде всего хорошее образование (Сингапурский национальный университет в данном случае).

Просто перепиши это дерьмо на плюсы или раст, а лучше всего на сишечку.

Будь как Xyun!

Книга Роберта Мартина о принципах SOLID, проектировании компонентов и пакетов, имеет объём 700 страниц. Классика DDD имеет объём 500 страниц. Функциональное моделирование домена на F# - 300 страниц. Книга по внедрению зависимостей имеет объём 500 страниц. Функциональная архитектура Гранина на хаскеле -- 500 страниц. Software Architecture with Kotlin -- 400страниц. Гексагональная архитектура - 200+ страниц. Software Architecture with C#12 - 700 страниц. Даже Head First Software Architecture для малышей с картинками имеет объём 400+ страниц.
И так далее...

Моя лебединая песня -- свернуть всю эту информацию с минимальной потерей смысла в несколько десятков (в идеале -- сотен:) раз, и отдать вам.

В архитекторстве, на самом деле, как ни проектируй, в конечном итоге при правильном использовании паттернов всё равно получается функциональная архитектура, как финальное формальное обобщение этого всего :)

Как функциональное программирование само по себе не инженерное изобретение, а математическое открытие, также и функциональная архитектура есть нечто похожее, которое святым computer science удалось открыть научным способом. Она независимо материализуется в самых разных системах (просто чаще всего вы это не подозреваете, как и наличие монады в каждой тысяче строк вашего кода :), а затем вдумчивыми специалистами впоследствии обнаруживается как математическая по сути закономерность.

...Удачно наткнулся на свежую книгу "Hexagonal Architecture Explained" - вышла в этом году! - Алистера нашего Коберна, автора легендарной гексагональщины (а также one of the "42 Greatest Software Professionals of All Times"). Предвкушаю наслаждение от её изучения и последующей декомпозиции :)

btw, в этом году на GOTO Copenhagen 2025 Алистер проводил свой однодневный воркшоп по гексагональной архитектуре на несколько десятков человек, каждый из которых платил около 800 долларов :)

"Шестиугольная архитектура настолько же неправильно понимается, насколько ее популярно цитировать", ну и конечно же, только "на этом однодневном семинаре вы узнаете, как это сделать правильно".

"По итогам этого семинара вы получите два сертификата уровня A Heart of Agile Academy: один за упражнение "Карпаччо из слоновьего мяса" (Elephant Carpaccio), и один за гексагональную архитектуру."

=

Хотел тут пошутить про инфоцыганщину, штрафы за обучение с выдачей сертификатов без лицензии, и в кутузку за курсы когда "всё это есть в интернете бесплатно", но как-то не получается...