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

💬 "Джордж Акерлоф в классической статье «Рынок лимонов» на примере рынка подержанных автомобилей показал, как асимметричность информации может привести к краху рынка [3].
Предположим, существует две категории подержанных автомобилей:
«лимоны» (автомобили плохого качества) и «персики» (автомобили хорошего качества). Предположим далее, что владелец каждого «лимона» готов продать его за 1000 долларов, тогда как каждый потенциальный покупатель готов заплатить за «лимон» 1500 долларов.
Допустим, владелец «персика» готов продать его за 3000 долларов, а потенциальный покупатель готов заплатить за него 4000 долларов.
Если бы качество автомобилей было с самого начала очевидным для каждой из сторон, тогда рынок работал бы должным образом. Все автомобили можно было бы продать: «лимоны» — по цене от 1000 до 1500 долларов, а «персики» — от 3000 до 4000 долларов.

Но что если каждый продавец знает о качестве своего автомобиля, а покупателям известно только то, что на вторичном рынке половина автомобилей — «лимоны», а другая половина — «персики»? Если бы автомобили этих двух категорий предлагались на продажу в равной пропорции, каждый покупатель был бы готов заплатить не более чем ½ × (1500 + 4000) = 2750 долларов.
Владелец, который знает, что его автомобиль относится к категории «персиков», не захочет продавать его по этой цене.
Следовательно, на рынке будут продаваться только «лимоны». Покупатели, зная об этом, будут предлагать максимум 1500 долларов.
Рынок «персиков» полностью прекратит свое существование, хотя покупатели и готовы платить за «персики», качество которых может быть доказано, вполне приемлемую для продавцов цену. Это полностью разрушает чрезмерно оптимистичную интерпретацию рынка, которая состоит в том, что рынок — это самый лучший и самый эффективный институт для ведения экономической деятельности."
-- "Теория игр. Искусство стратегического мышления в бизнесе и жизни" / Авинаш Диксит и Барри Нейлбафф ; пер. с англ. Н. Яцюк. — М. : Манн, Иванов и Фербер, 2015.

Сложный вопрос. Постараюсь.

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

Существует модель решения, т.е. упрощенная интерпретация реальности с целью решения некой проблемы. Это модель области решения, которая подлежит реализации.

Эти две модели могут отличаться. Основная идея DDD заключается в том, чтобы они не отличались, т.е. чтобы эти две модели совместить в одну. А поскольку натуральный язык - это тоже модель, то для достижения этого используется Ubiquitous Language, т.е. использование единых терминов как специалистами области решения (разработчиками), так и специалистами области проблемы (экспертами предметной области). В этом заключается основная суть DDD.

Но т.к. количество терминов ограничено, а количество явлений предметной области безгранично, то языковые конфликты (разные явления под одним термином и, наоборот, разные термины одного явления) являются маркерами границ модели, которые называются Bounded Context.

Основных целей у BC две:
1. Снизить когнитивную нагрузку, т.е. модель не должна содержать ничего неревантного решаемой ею проблемы, чтобы не создавать паразитную когнитивную нагрузку.
2. Снизить коммуникативную нагрузку, т.е. модель не должна быть разделена между разными командами, которые не смогут и шагу ступить без коммуникаций, не сломав при этом инвариантов модели.

Основная суть EventStorming заключается именно в том, что он позволяет моделировать решение прямо поверх ментальной модели стейкхолдеров, прямо на тех же стикерах. Результатом ES является модель решения, которая в точности отражает структуру будущего кода. Настолько точно, что по этой диаграмме можно делать автоматизированную сверку кода, или даже генерировать сам код, с помощью инструментов, которые я упоминал ранее (на Java это можно сделать используя сервис от Vaughn Vernon domorobo.to + xoom-designer).

"ВКонтакте" отказалась от микросервисов | ComNews
https://www.comnews.ru/content/228980/2023-09-25/2023-w39/1008/vkontakte-otkazalas-mikroservisov

Новая книга от PostgresPro:
Лесовский А. В. Мониторинг PostgreSQL. — М.: Бумба, 2024. — 247 с.
https://postgrespro.ru/education/books/monitoring

Уходят титаны...
https://x.com/Bertrand_Meyer/status/1742613897675178347?s=20

Некоторые ссылки битые потому, что блог автора переехал с frey.su на frey.today Правильные ссылки смотрите в блоге автора:
https://frey.today/blog/

Тг-канал Дениса Бескова сменил свой адрес на https://news.1rj.ru/str/denis_beskov

Думаю, что в представлении он не нуждается. Один из самых грамотных специалистов, которого я только встречал за всю свою практику. Именно он организовал нашумевшее недавно интервью в Владиком Хононовым.

Автор профстандарта системного аналитика, основатель школы системного анализа и проектирования, организатор и спикер конференций, в свое время построил отдел системных аналитиков в Лаборатории Касперского.

Подписывайтесь)

Еще один список инструментов для управления требованиями:
http://makingofsoftware.com/resources/list-of-rm-tools

💬 "Машина может быть на ДВС, но машина - это не "то, у чего внутри ДВС", машина - это на чем ездят."
-- @IgorBespalchuk

Простыми словами про дихотомию функции и конструкции. Problem Space vs. Solution Space.

Иногда хочется так много сделать, но так мало получается сделать. А у него получилось. И я хорошо понимаю, какой титанический труд за этим стоит. Хочу пожелать успехов и дальнейшего развития.

Кстати, недавно я стал случайным слушателем его курса для бизнес-аналитиков. И был впечатлен.

Не реклама. Мое мнение. Потому что хочу, чтоб таких качественных курсов было побольше на нашем захламленном рынке знаний.

Кто не хочет погружаться в работы Barry Boehm для выбора SDLC-модели разработки, тот может использовать более простой подход - Cynefin framework (см. мини-книгу в канале @nullnullday )

Постараюсь посетить:
https://news.1rj.ru/str/denis_beskov/165

Там все чуть сложнее. Если совсем просто объяснять, то итерация - это "метод научного тыка".

Бытовой пример. Например, нужно обесточить и заменить розетку. Видим в щитовой кучу автоматов. Какой из них выключить? Можно, конечно, определить путем логического вывода, например, отыскать схему разводки или исследовать разводку детектором скрытой проводки. А можно просто включить в розетку лампочку и поочередно перебирать все рубильники до тех пор, пока не угадаем.

Как говорил математик Polya: "If you run into a dead end in one of the areas, iterate!".

Суть итерации в том, что иногда проще сделать и изменить, чем пытаться угадать с первого раза.

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

Решение оказывается мертворожденным. Чтоб его оживить, возникает соблазн окутать его метастазами системы.

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

Система отражает то, что творится в головах программистов. А значит, здоровье системы начинается отсюда. Это и есть фундамент. Согласен с Gregor Hohpe в том, что табуретка архитектора о трёх ногах: Skill, Impact, Leadership.

Лидерство. Архитектор или становится вождем и принимает на себя ответственность за судьбу проекта, или он рисует мертворожденные стрелочки с квадратиками где-то на обочине жизненного русла продукта. Еще недавно подобное явление называли "хвостизм". Наверное, поэтому первой книгой в списке от Gregor Hohpe идет книга "Clean Code". А второй - "Refactoring".

💬 "When designing a single software component, architects should focus on good coding and design practices." -- Gregor Hohpe

Знания программистов - это первое, с чего я всегда начинал работу на новых проектах. И только потом - стрелочки и квадратики. Тем более, что в Screaming Architecture эти стрелочки не так уж сильно и нужны. А от лапшы они все-равно не спасают.

Лекционный формат не работает. Одна картинка стоит тысячи слов. Поэтому важно сделать один сервис образцово-показательным. А дальше copy-paste сделает свое дело. Программисты часто прибегают к копированию. Было бы что копировать. Если копировать нечего, тогда наступает царство "Теории разбитых окон". Если копировать нечего, то оно само не появится (иначе появилось бы раньше). Значит, его должен создать архитектор. Сам, или совместно с программистами, - зависит от ситуации.

Обычно странглирование оказывается эффективней рефакторинга. Странглирование еще и выгодней по политическим причинам - новое будет хорошо контрастировать на фоне старого. Это если, разумеется, архитектор умеет в код, и умеет быть лидером.