В среду, 24 февраля в 19:00 MSK
проведу небольшой стрим на эту тему. Ссылка трансляции на YouTube: https://youtu.be/S8JMVXAfFOM Вопросы можно задавать в комментариях к этому сообщению или в анонсе на FB: https://www.facebook.com/events/3781729695241571

Если вы не любите задавать вопросы, но готовы поделиться своим мнением, то тоже не стесняйтесь. Жду всех в среду вечером, присоединяйтесь!

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

А скоро уже трансляция: https://youtu.be/S8JMVXAfFOM

В одной из компаний, в которой я когда-то работал, ИТ-архитекторы делились на два вида: системные и бессистемные.

Системными называли тех, кто отвечал за развитие какой-то конкретной информационной системы, а бессистемными – архитекторов, проектировавших решения и интеграционные взаимодействия. Я еще шутил, что им просто своей системы не досталось. Возможно, термин этот был немного обиден, но мне он нравился. Да и архитекторов этих вскоре стали называть solution architect.

А вспомнил я о том, прочитав свежую реплику Анатолия Левенчука, которой хочу поделиться с вами https://ailev.livejournal.com/1557247.html Сразу скажу, что мне порой доводилось встречать еще одно, третье понимание системного мышления, не совпадающее с рассмотренными в этом тексте. Но обобщение, которое я для себя принял исходя из этого и подобных рассуждений в том, что при встрече с термином системный, или производными от него, лучше проявить некоторую настороженность

Сейчас просто предложение договориться о терминах для людей, хоть чуть-чуть знакомых с тем же DDD, выглядит несколько стрёмно. Оно может рассматриваться как приглашение в чужой ограниченный контекст или же попытка нарушить границу вашего (Пришли тут инженеры учить айтишников программы писать)

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

Так стоит ли договариваться о терминах? Давайте отдадим предпочтение пониманию

Я давно слежу за выступлениями Жамак Дегани, но не знал что есть переводы её текстов на русский https://habr.com/ru/post/495670/

Поделюсь приглашением из чата

В чате это сообщение может потеряться, поэтому поделюсь здесь

Я, как это всегда и бывает, пропустил самое интересное. На этот раз речь о серии из шести прошлогодних заметок, которые Gregor Hohpe озаглавил Thinking Like An Architect. Мне на глаза попалась только пятая Architects Zoom In and Out, See Different Things в которой он пошагово улучшает ;) картинку из книжки Марка Ричардса и Нила Форда The Fundamentals of Software Architecture.

Естественно, я посмотрел и остальные. Серия начинается здесь: https://architectelevator.com/architecture/famous-architects-sketch/ А посетовать я хочу на то, что мне более чем симпатичны идеи автора, но, почему-то, совершенно не нравятся его тексты. Может у кого-то сходные ощущения?

А теперь время согласиться и одновременно поспорить с уважаемым Грегором Хоупом. В первой статье цикла Мыслить как архитектор он замечает, что архитекторы (не айтишные, проектирующие дома), создающие эскизы зданий, иногда в виде скетчей на салфетке, зарабатывают много больше инженеров, разрабатывающих чертежи поэтажных планов и схем электропроводки. Но автор никак не может ухватить слово, описывающее их деятельность: abstraction не abstraction, illusion, gestalt… Хотя, на мой взгляд, здесь вполне подошло бы слово ideation, т.е. концептуализация – формирование понятий или представлений. И все дальнейшие разговоры об «устранении шума» в эскизах, выделении главного и пр., встречающееся и в первой, и в пятой заметке цикла, выражаются этим словом.

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

Подборка информационных рассылок по архитектуре ПО от Екатерины Новосельцевой https://dzone.com/articles/15-software-architecture-newsletters-that-are-wort

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

Еще середина марта, а Apple уже придумал первоапрельскую шутку: https://www.vedomosti.ru/technology/articles/2021/03/15/861564-iphone-soft

Поделюсь статистикой использования моделей и диаграмм https://habr.com/ru/company/accenture/blog/547136/

Вчера появилась новая версия 1.4 Enterprise Architecture on a Page от Svyatoslav Kotusev http://eaonapage.com/ Впервые она стала цветной

22 марта в 15:00MSK - хорошее время провести первый голосовой чат в нашем новом телеграмхаусе. Прямо здесь, на этом канале, мы немного поговорим о вещах, которые связаны с Domain Driven Design, но полезны и в более широком контексте. В общем, разговор будет на тему NoDDD.

Делитесь этим приглашением и присоединяйтесь!
(Ссылка на FB: https://fb.me/e/bVMiI2xKL)

Великолепно!