Не очень слежу, но тем не менее, в марте в гошечке 1.18 завезли генерики)

Я помню как они появились в c# 2.0 (а до этого я только у читал про них у Майерса). И это был кайф!

https://go.dev/doc/tutorial/generics

Давно не писал в канал, не мог найти времени, а все от того, что параллельно работаем над такими вещами, как:
- референс-архитектуры, в том числе микросервисные, в том числе ддд-compliant (детали тут: https://news.1rj.ru/str/emacsway_log/888)
- возрождение архитектурных ката, попробуем перезапустить с @Kirill_vet
- российская сертификация/база знаний в области разработки и проектирования (от сообщества для сообщества). Понятно, что нет такого понятия, как «российская специфика», но есть определенный базис, который нужен и хорошо, если мы сможем его давать внутри страны 👍получится - хорошо, не получится - чему-то научимся :)
- ddd проникает во все большее число компаний, растет интерес к применению ddd для отображения в орг структуру. Чему я несказанно рад, потому что при проектировании микросервисов так или иначе всегда строили модель предметной области, а вот предложение перенести эту модель в орг структуру и бизнес-архитектуру принималось через раз (где принималось, те понимают о чем я 😉). Готовлю выступление «оргдизайн через ddd». Кстати, это буквально воплощение закона Конвея.
- со дня на день стартует подготовка к archdays. Оффлайн🤞, наверное все же с онлайном, ибо странно не использовать этот канал совсем. Уже есть заявки, ждем еще 👀

Пошла жара вокруг ДДД. Имхо когда мы говорим о какой-то практике, нужно четко разделять:
1. Академическую часть
2. Приклад
3. Контекстно-зависимое применение

Поясню на примере ДДД.

Академическая часть - это Эванс, Вернон, работы о самом ДДД, теория сложных адаптивных систем, моделирование, системное мышления и проячее. Академическая часть нужна для того чтобы:
- развивать фундаментальные основы, независимо от приклада
- обучать прикладным вещам (да, для этого важно понимать, на чем они основаны)
2. Приклад. Например, - дизайн организационной структуры, принятие управленческих решений на основе типов доменов (что инхаус разрабатывать, что отдать на аутсорс), проектирование микросервисного решения
3. Контексто-зависимый приклад - например, Банк, CRM, ритейл, Поиск. Для применения здесь не нужно даже знать терминологию ДДД, и даже вообще знать что есть какое-то ДДД, но тому кто будет проектировать или строить модели, проводить совместное исследование домена, безусловно, нужны знания и на академическом и на прикладном уровне (а вот контекстно-зависимый приклад уже не так важен, его нужно структурировать усилиями участников совместной практики).

И так с любой практикой, имхо. Есть популярный узкоспециализированный приклад, есть принципы и основы на которых он построен и их знание позволяет подстраиваться под любые специализации в рамках области определения и есть еще более фундаментальные основы, которые дают понимание самых базовых принципов.

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

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

Буду рад обсудить в коментах.