...Более того, у многих не получается создать что-то работающее даже просто в модели обмена сообщениями (база: изучайте akka, erlang, ну и формальную логику ↑↑↑ :)

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

Признаю, это полностью моя недоработка 💯
как закончу второй курс по гомотопической теории, плотно прям берусь за доработку практики ООАП, забустим её моделью акторов Хьюитта.

HoTT же, думаю, останется навсегда лишь для самых умненьких (только 0,002% способны.... :).

=

Software/System Design -- это про то что вне зависимости от объёма вашего проекта у вас обязательно там и тут будут образовываться big balls of mud конкретно в вашем коде. И тут важно эксплицитно разделять три типа этого дерьма:

-- DevOps и System Design in Large: бесконечные архитектурные боли и страдания , связанные с интеграцией чужих каках (все эти опенсорсные либы, микросервисы брокеры балансировщики очереди куберы-шмуберы), подчас вообще чистый devops, который сегодня стало модным скидывать на чистых разработчиков;


-- System Design in Small: технические возможности кривейшие ограничения, накладываемые фреймворком, все эти MVC ORM...


-- Software Design/Programming in Large: наконец, собственно программный код, ключевая мякотка везде и всегда. Вы никуда не уйдёте от того, что в абсолютно любом крупном проекте обязательно будут сотни-тысячи сущностей, как их не обзывай (типы данных, классы, таблицы базы..), и вам придётся как-то увязывать (скорее всего асинхронную) логику их работы.

Я делал и буду делать акцент только на этом пункте, трек ООАП ровно про это. Девопсу и SD вас научат сегодня в любой подворотне, потому что это то что можно в проекте "пощупать", а вот PiL фактически нигде не найти (слишком абстрактно, примерно как рефакторинг для менеджеров).

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

Склоняюсь к некоему учебному прототипу dwarf fortress (в тележке русский чатик очень живой)
Миллионы строк кода на плюсах, тысячи сущностей, и при этом уникальная сложность (глубокая симуляция физики, экономики, биологии ...)

Посмотрите легендарный тред " Dwarf Fortress source code":
the source code is so mind-buggeringly complicated and idiosyncratic that nobody else except Toady can really understand it

Тут ведь самое важное вот в чём: не запутаться в первых 16, 64, 256, 1024-классах, причём первые 2-3 шага ключевые. Хочу продемонстрировать вживую и, главное, "научать", как можно с самого начала и на всю перспективу удерживать линейной сложность программного кода с логикой взаимодействия тысяч типов сущностей в реальном времени даже для неоднозначного и нечёткого ТЗ с постоянными новыми хотелками.

И главное, чтобы это было доступно любому миддлу, этих ваших универов не заканчивавшего.