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

Рассказывают, что однажды к известному физику Резерфорду пришел студент и попросился в ученики.
"Не вопрос! Давайте!" - ответил Резерфорд. "А что мне делать?" - спросил студент.
Резерфорд дал ему некоторое задание и отправил изучать и работать.
Через неделю студен вернулся со словами: "Я все сделал. Что мне делать дальше?".
Резерфорд удивился и дал ему новое задание. Через пару недель студент снова пришел со словами: "Я все сделал. Что мне делать дальше?". Резерфорд очень удивился и дал новое задание.
Когда студент через какое-то время снова пришел: "Я все сделал. Что мне делать дальше?", Резерфорд его выгнал.

Как вы думаете, почему он так поступил?

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

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

Как же внедрять правильные практики в организации?
Вероятно, нужно требовать не столько применять конкретные практики, сколько отслеживать и предъявлять требования к другим характеристикам/метрикам деятельности - например, скорость принятия архитектурных решений, частота переделок, количество ошибочных решений и т.п., достигнуть которых сложно без применения правильных практик, инструментов, технологий. Иными словами, создавать условия, в которых в командах возникнет потребность в зарождении полезных практик.

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

Преза почитать для тех, кто пропустил.

Я из тех, кто пропустил :) И сейчас с интересом почитал.
Стало гораздо понятнее, что именно происходит сейчас нашей компании.

Since a bounded context is a boundary for a model, it could include concepts from multiple subdomains. Or a single subdomain could be modelled as multiple bounded contexts.

Subdomains vs Bounded Contexts: Areas of the domain vs boundaries of models of the domain.

#DDD

https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c?utm_source=pocket_mylist

Имел вчера удовольствие полуручного мерджа веток в Archi ☹️

Выяснилось следующее. Archi (точнее, collaboration плагин) хранит специализации в файлике model/folder.xml. Если изменения в составе специализаций делались в двух сливаемых ветках, то при мердже какая-то часть может потеряться, т.к. плагин детектит конфликты только на уровне объектов и диаграмм, а специализации, похоже. сливает "как получится".

В моём случае специализации добавлялись в обоих сливаемых ветках, и, похоже, при автоматическом мердже что-то потерялось. При этом Арчи полученную модель открывает, но при попытке её сохранить ему сносит мозг, он ругается про orphaned profile и не даёт сохранить модель.
Разрулить ситуацию удалось, сделав ручной rebase средствами гита, без участия Archi, и решая конфликты на уровне xml-ей. Потом руками перетащил XML файлы некоторых диаграмм из master и вроде модель открылась и заработала.

Резюме.
Составом специализаций лучше управлять в одной ветке, не нужно их мерджить средствами Archi.
#archi

Вот интересно стало, насколько связаны и коррелируют между собой DDD и DSL? Одна из сильных сторон DDD заключается в том, что программные модели формулируются на едином языке, максимально близком к понятиям предметной области - домена. Это позволяет минимизировать искажения при преобразованиях понятий и требований. Насколько я понимаю, DSL решает примерно те же задачи, но чуть с другой стороны. Тут не важно, как программа устроена внутри, фокус именно на языке, который позволяет описывать происходящее в терминах предметной области.

В студенческие годы на вычислительном практикуме я писал программу, которая решала систему линейных уравнений методом то ли вращений, то ли отражений, уже не помню. Как правило, подобные учебные программы пишутся "в лоб", в терминах массивов, переменных и действий с ними. Читать такую программу сложно, текст программы даже близко не напоминает формулы из учебника. Если что-то не работает, то понять где именно ошибка крайне сложно...

А я тогда как раз научился переопределять операторы в С++, так что мне захотелось "сделать красиво". Я написал классы вектора, матрицы, определил для них операторы сложения и умножения, добавил нужные методы для транспонирования, вычисления нормы и т.п. Каждый из этих методов был достаточной простой и очевидный. Благодаря им, функция, реализующая метод решения системы уравнений, выглядела почти дословной копией строки учебника.

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

К чему был предыдущий 👆 слегка спонтанный спич.
А к тому, что DDD, подобно DSL способствует выделению понятий, терминов и прочих элементов единого языка, на котором описывается как логика предметной области, так и логика работы приложения. И если модель, используемая в программной части "изоморфна" понятиям предметной области, то описание алгоритмов и действий предметной области происходит достаточно легко и просто.
В DDD сложность, как и в моем примере выше, фактически смещается с задачи программирования собственно алгоритмов и бизнес-логики в задачу создания адекватной модели реального мира предметной области.

ИМХО, важно понимать, что задача моделирования языка и задача реализации содержательной логики приложения - это разные задачи. И если в "классической" реализации основная сложность находится в реализации логики, то в случае DDD сложность смещается в сторону модели, а логика программируется и модифицируется легко и просто.
Если не разделить в голове эти две задачи, то читать книги и статьи по DDD довольно сложно, так как не понятно даже зачем все эти сложности и заморочи с контекстами, агрегатами и т.п. А они как раз таки помогают сделать адекватную модель, но не само приложение. С другой стороны, если есть адекватная рабочая модель, которая терминологически соответствует бизнесу, с гарантией соблюдения инвариантов - то сделать на ней приложение уже никакой проблемы не составляет, нужно лишь почти дословно переписать нужные утверждения из учебников, ТЗ или из протокола встречи с заказчиком.

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

Интересный результат...

Есть такая забавная штука - оценка чего-то. Архитекторов часто просят оценить сроки, стоимость, ресурсы. А когда оценка не совпадает с реальностью, то говорят, что оценка была неточной... А могут ли оценки вообще быть точными?

Есть две крайности.
⭐ Первая крайность - оптимистичная оценка. Такая оценка обычно не учитывает риски, выдается в предположении что ничего плохого не случится, поставщики все привезут вовремя, никто не заболеет, а данных в базе будет ровно столько, сколько кажется сейчас, и никаких новых вводных не придет.
С одной стороны, так не бывает. Вероятность вписаться в такую оценку практически равна 0, но, с другой стороны, такая оценка - это очень полезная величина. Можно с большой уверенностью сказать, что лучше точно не будет.

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

👉 Скорее всего реальные сроки, бюджеты и ресурсы окажутся где-то между оптимистичной и пессимистичной оценкой.

❓Но вот где они окажутся?

Как же повысить точность оценок? Купить колоду карт Таро!

✍️ Во-первых, я предлагаю относится к оценке не как к попытке угадать реальность, а как к психологической величине, примерно как к ставке в игре "угадай мелодию":
" - Я смогу реализовать данную фичу за 14 дней "
" - Реализовывай! "
Такой подход переводит процесс оценивания из пассивной попытки "измерения будущего" в область квантовых эффектов, когда оценивающий влияет на объект оценки. После оценки не нужно пассивно ждать, пока все случится, чтобы сравнить оценку и реальность, а наоборот, следует активно воздействовать на реальность, чтобы она не сильно расходилась с оценкой, и оценку выдавать, в том числе, исходя из своих возможностей влияния. (а также и возможных последствий "промаха" :) )
👉 Оценка - это величина, в которую вы верите, и которая не сильно пугает.
Круто, если вы можете её обосновать расчетами. Но это вторично, первично именно психологическое отношение :).

✍️ Во-вторых, нужно учитывать, кто и зачем спрашивает оценку. Обычно у спрашивающего есть свой психологический или экономический "порог целесообразности" оценки. Например, бюджет проекта ограничен, и если оценка превышает этот бюджет, то он теряет смысл.

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

Чем больше у вас будет возможности в будущем влиять на реальность, чем более стабильно и предсказуемо окружение - тем ближе оценка к оптимистичному краю📉. И наоборот, чем меньше стабильность, чем меньше влияния - тем больше оценка смещается к пессимистичному краю 📈.

👉Итого, методика получения "точной" оценки звучит так:
двигать оценку между крайностями, стремясь удержать её в диапазоне целесообразности
и добиваясь чувства психологического комфорта 🙂

💭 Кстати...
Ваша итоговая оценка может в разы превышать порог целесообразности.
Это не криминал, а лишь повод для переговоров.

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

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

Если кто-то зайдет на кухню и окликнет меня, пока я отмеряю кофе - я обязательно собьюсь, и придется считать заново. Если положить в турку сначала сахар, а потом кофе, то если я сбился - у меня образовалась смесь сахара и неизвестного количества кофе, с которой непонятно что делать. Я не могу "откатить" эту смесь обратно в банку с кофе. А если сначала класть кофе, то возможный сбой операции будет безопасен, в случае отказа счетчика ложек можно безопасно пересыпать кофе обратно в банку и начать считать заново. Теоретически, подобный сбой может произойти и при добавлении сахара, но там вероятность отказа существенно меньше, так как сахара я кладу немного, 1-2 ложки, тут я уже не собьюсь со счета.

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

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

На практике же все совсем не так. На начальном этапе продукта/проекте еще кто-то думает про архитектуру, рисует красивые схемки, модели и прочие описания, потом по ним что-то реализуется... А дальше система сама по себе, а архитектура - сама по себе. В лучшем случае есть реестр ADR-ок, как набор событий в Event Sourcing. И если тебе надо понять, что же там в системе на самом деле - то надо либо прочитать и осмыслить весь журнал ADR-ок, либо идти реверсить код. И второй вариант кажется более практичным...

Пытаюсь выстроить работу с архитектурой, как с моделью, на практике.
Пришел к тому, что нужно развивать поддерживать следующие модели:
1. Модель текущего состояния системы. Отражает факт. Применяется для анализа возможных изменений, онбординга, источник картинок для документации по системе. Акцентируется на фактическом состоянии архитектурных элементов и их взаимосвязей.
2. Модель возможного будущего. Отражает мечты и возможные планы. Используется для для планирования будущих работ и презентаций руководству. Зыбкая, часто изменяемая. Акцентируется на крупных элементах и отношениях, без внимания к деталям.
3. Модель планируемых изменений. Отражает изменения текущего состояния в рамках постепенного движения к светлому будущему. Акцентируется на том, какие архитектурные элементы нужно добавить/изменить/удалить в рамках развития системы. Из таких моделей формируется ADR.

Осталось только придумать, как всё это реализовать на Archi.
#моделирование #archi

Продолжение. Начало - https://news.1rj.ru/str/sysarchthoughts/71.
Итак, рабочая гипотеза следующая.

Основной тезис - все перечисленные выше виды моделей буду вести в одном файле-модели Archi.

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

Структура моделей задаётся папками, в которые раскладываются представления.
Верхнеуровневая структура папок выглядит так:
📂 Baseline - представления, которые описывают текущее состояние системы. Внутри они сгруппированы по типам/назначению (модели данных, описания поведения, структуры, развертывания и т.п.). Представления из этой папки берутся как базовые для новых задач, требующих архитектурного изменения
📂 Cases - сгруппированные по кейсам/задачам представления планируемых изменений архитектуры. Одна папочка - одно качественное изменение, описываемое в разных аспектах. Одновременно в работе может находиться несколько кейсов, которые ведут разные архитекторы. Каждый работает с представлениями в своей папке, это позволяет избегать конфликтов слияния.
📂 Future - представления, описывающие возможные варианты будущей архитектуры.
📂 Archive - папка с представлениями, которые не находятся в активной работе, но которые жалко удалять хочется сохранить.
Это завершенные кейсы, отклоненные варианты будущего, устаревшие представления текущего состояния и т.п.

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

Сначала я предполагал, что изменяется непосредственно представление в baseline, сейчас пришел в решению, что представление именуется в соответствии с версией/номером релиза приложения/системы, архитектуре которой оно соответствует. При выходе версии с изменениями делается копия представления, которая именуется под новую версию, в ней отражаются внесенные изменения, а старая версия идет в архив.

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

#моделирование #archi

Продолжение мысли, высказанной ранее https://news.1rj.ru/str/sysarchthoughts/21.
Сложные методы работы (типа DDD), нацеленные на предотвращение сложных проблем в возможном будущем, почти неизбежно будут внедряться с большим трудом. Почему так?
Во-первых, сложные проблемы возникают в командах с высокой квалификацией, потому что без неё до сложных проблем не добраться, завязнут в простых.
Во-вторых, людей с высокой квалификацией объективно сильно меньше, чем со средней или невысокой. Ну, это банальная статистика.
Следствие - для подавляющего большинства проблемы, на решение которых нацелены подобные методы - это просто слова, абстракция. Они этих проблем не видели и не могут оценить их значимость или сложность. А вот сложности, которые привносит метод, они не гипотетические, а вполне ощутимые.

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

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

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

Что с этим делать, честно говоря не знаю. 🤔
Будете смеяться, но пока единственный подход к борьбе со скептицизмом внедрения подобных сложных практик, который у меня реально работал - это довод, что делать "вот так", как минимум, существенно интереснее, чем по-старинке.
Т.е. внедряем Just for fun, и пользуемся с удовольствием 😃

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

Тут есть очень тонкий момент ... с одной стороны DDD как раз говорит о том, что нужно разделять модели по контекстам, с другой стороны - на ранних этапах это сильный оверинжиниринг.
Мне видится, что истина - где-то посередине. Т.е. не стоит стремится на старте сразу сделать "полную и правильную" карту контекстов, это все равно невозможно - придут новые вводные и карту придется перестраивать, и чем больше наработали по этой карте, тем больше придется переписывать.
С другой стороны, совсем без карты нельзя, поэтому в каждый момент времени должна быть актуальная гипотеза о будущей целевой карте контекстов (та, в которую мы верим и которую подкручиваем по мере появления новых вводных), и одновременно упрощенная карта текущего состояния, в которой может быть какие-то контексты объединены, какие-то отсутствуют, но у нас есть четкое понимание как, в какой ситуации и какие изменения модели будут предприняты, чтобы прийти к целевой карте.
Это означает, что мы, действительно, можем начать с простого монолита, например, с общей модели заказа, но эта модель развивается не стихийно, а мы как бы закладываем ростки будущего разделения в архитектуру, в принципы построения системы, и разваливаем контексты и модели на части, как только возникает такая необходимость.
с одной стороны, такой подход позволяет избежать лишних усложнений на старте, а с другой, его реализация требует еще более высокой квалификации, опыта и "насмотренности", чтобы контролировать архитектурные принципы еще до того, как они нашли фактическое воплощение в реальном выделении модулей, интерфейсов и сервисов.
Грубо говоря, писать простой код оказывается еще сложнее, чем писать сложный :)