ИМХО статья явно нуждается в более глубокой проработке и хотя бы в нескольких десятках часов целенаправленного рисерча

да автор вообще дебил ) это я.

вот только про erlang там ни слова. этот язык далек от того про что бизнес. у него есть нишевые применения.

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

да есть C, C++, Erlang, Rust и много чего еще прикольного и веселого. Но это менее 1% от реального мира.

на этом кодят сверх люди. где то в мире далеком от бизнеса.

там конечно могут быть разные спецэффекты и эксклюзивы.

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

в статье даются ссылка на интересный митап skyeng. мне понравилось.

там ребята сильно теоретизировали. но ворвались пара бойцов, которы сильно поставили все на свои места. про реальный мир, прикладной, про бизнес, который занимает 90% экономики.

да есть наука, рокет сайнс, где сидят топ программисты, которые думают высокими материями. все круто.

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

там не существует хай-лоада.

там есть инструменты для бизнеса. то чем можно пользоваться. для реальных людей в реальном мире. и вот там играет важную роль high-extensible. о котором и идет речь в статье.

high-load это все таки про яндекс, про гугл, про людей, которые прям 1%.

об этом все статьи на хабре, на конференциях. все круто. я за.

но статья то про другую часть мира. про реальные беды бизнеса.

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

или даже про компанию где есть 100-200 разработчиков, но надо управлять конфликтами в команде и прочими атрибутами.

это иной мир. мир где надо делать продукты. и не стрелять друг другу в ноги.

Я вижу в этих рассуждениях два слабых места. 1) противопоставление DDD и строгой типизации. Они друг другу никак не противоречат. Более того, в DDD два базовых понятия, entity и value object - это, в какой-то мере, строгая супертипизация, когда мы говорим, что те или иные сервисы  принимают на вход только вот такие объекты, а вот эти aggregate roots могут агрегировать только вот такие элементы. PHP, кстати, который год семимильными шагами движется в сторону строгой типизации.

2) ассоциирование DDD и EDA. Можно писать очень чистый код, и при этом либо вообще не использовать события, либо использовать их ограниченно там, где это архитектурно оправданно. И это хорошо, потому что всё, что связано с событиями и их обработкой - это часто больно и сложно в понимании новым людям в команде.

Классная мысль. Спасибо )

DDD конечно не противоречит строгой типизации или другой типизации. Можно что угодно использовать.
Но Алан Кей, Дэвид Уэст, ребята из айспринг и я лично пришли к выодам что динамическая типизация в этой теме круче. Но это мелочи. Гораздо важнее домены, события и границы доменов. Это целое искусство.

Про чистый код не готов комментировать. Для меня это что то далёкое от реальности. Я понимаю лишь читаемый код и не читаемый. Прочитав десятки стилей кода. От джуниоров до сеньоров. Сотни проектов и репозиториев на гитхаб. Я понимаю что есть код который легко понимаю, а есть такой код который мне понять тяжело. И это субъективно. Но я пишу код и получаю сообщения от людей из РФ и других стран где люди говорят что мой код легко читать и просто модифицировать. Смею надеяться что понимаю как писать код. Однако это также зависит от того кто читает и владеет архитектурой кода.

События действительно сложнее в чтении и отладке чем тот же MVC. Типа простой Симфони или ларавел. Если мы говорим о простом микросервисе. Берём идеи которые отражены в симфони демо и спокойно работаем. Все просто и всем понятно.

Однако этот подход начинает дико ломаться и создавать проблемы когда мы делаем что то более сложеное. Когда мы работаем с большой системой, где есть более 2х команд, и в каждой команде более 5-10 программистов. Там начинаются сайд эффекты и проблемы. Команды начинают конфликтовать или делать двойную работу. Вот там то и нужно делать DDD & EDA, которые с одной стороны чуть чуть усложняют код, с другой стороны решают проблему переиспользования кода и взаимодействие команд. Эта штука может масштаьироваться до 100 и более команд без лишних рисков. Но работает это всё только там где в командах существует культура такой разработки.

Иначе создаётся ситуация когда культура хавает стратегию на завтрак. Вся эта штука не работает если команда не привыкла к DDD & EDA. Или понимает это плохо.

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

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

Можно не говорить про вордпресс если это больно ))

Я лишь думаю что глупо полагать о том что платформа которая заняла 30% рынка плохо сделана. Она другая. И да не привычна. От того делает больно тем кто привык к MVC или похожим архитектурам.

В статье есть другие примеры. Которые по сути пытаются повторить тоже самое. В конечном итоге мы все равно приходим к DDD & EDA.

И к сожалению я вынужден констатировать, что доля рынка и технологическое качество в лучшем случае не коррелируют совсем, а в реальности имеют обратную корреляцию. Яркие примеры - Slack или JavaScript. Видимо пока кто-то пилит красивое решение - конкуренты из говна и палок запускают как получится, делают несколько итераций и завоёвывают пустые ниши.

Я не понимаю как можно нишу сайтов назвать пустой ))

По мне так это алый рынок где идёт бойня с фонтанами крови. Уже 10 лет.

Но в этой теме много заряженных мнений. Потому не хочу об этом говорить. Там куча других примеров.

тема интересная, но важно обозначать ограничения. 1 команда, 5 команд и 50 команд, работающие над 1 продуктом — требуют очень разной архитектуры. Здесь интересно спросить тех, у кого реально 50 команд, типа Сбербанка

кстати, господа, у кого из вас 5 раздельных команд (или 20+ человек) работают над одним продуктом, разделяя между собой общую кодовую базу. Расскажите, как решаете проблемы масштабирования

У меня вроде бы именно так и даже хуже (а в целиковом Поиске — и подавно), только я прям совсем не понимаю, о каких именно проблемах масштабирования идёт речь :)

Я говорил про слак конкретно, который стал де-факто стандартом корпоративного мессенджера, несмотря на чудовищное технологическое исполнение.

по моим наблюдениям количество это не все условия.

если это 50 команд каждая из которых живет в своем продукте, в своем репо, то особых проблем там не будет.

проблематика из статьи обычно проявлятся в 3х контекстах:
1. это 1 продукт и 1 репо и 10-50 команд, которые начинают конфликтовать при отсутствии модульности и границ доменов
2. это может быть 10 команд и 10 продуктов и 10 разных репо, но команды решают одни и те же задачи, потом приходит идея общие части кода вытащить в переиспользуемые модули. и вот тут команды начинают экономить на двойной работе, но тут же начинают стрелять друг другу в ноги, так как комит 1 команды ломает систему 2й команы. ну и там еще куча сайд эффектов образуется.
3. это может быть опенсорс платформа с бизнес логикой типа магазина, тасктрекера или хелпдеска. из примеров в статье. ты пишешь ядро и модули, которые затем транслируются на 10-100-1000 команд в мире. и важно не ломать их. причем это модули с высокой связностью из за бизнес логики, которая очень сильно отличается от composer или npm. и потому эти инструменты там не работают или работают очень плохо.

вот с этого вопроса все и началось )

я долго искал примеры практики в РФ. и вот недавно нашел видос с ребятами скайэнга. они молодцы и почти подобрались к этой архитектуре. связался с докладчиком. он мне дал ссылку на видео из айспринг, где эта же тема с той же проблематикой на очень хорошем примере была разобрана. ребята из айспринг прям очень круто реализовали эту архитектуру и подходы. DDD & EDA ровно так как я себе и представлял. очень круто и реально. и главное что им удалось решить все эти проблемы о которых у меня сейчас болит голова.

ребята из скайэнга сказали что всей командой пересматривали это видео несколько раз.

и я их понимаю. реально дико видеть такой масштаб мышления в РФ )

https://www.youtube.com/watch?v=xT25xiKqPcI

по моим ощущениям слак это как раз про HighLoad, а не про HighExtensible.

там нет никаких проблем которые можно как либо решить при помощи архитектуры HE.

там скорее всего проблемы которые решаются через HL архитектуру.

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

нормальные конторы когда дело доходит до 50 человек в одном проекте, пересаживаются на яву

oops

А как же Rust и C++?