🗞 Журнал архитектурных решений
Запись моего выступления на конференции бизнес- и системных аналитиков, а немножко и архитекторов Flow2023 https://youtu.be/Qt26BQXSsvA&t=220
- c результатами июльского опроса: Чем ИТ-архитектор занят чаще всего внутри
Запись моего выступления на конференции бизнес- и системных аналитиков, а немножко и архитекторов Flow2023 https://youtu.be/Qt26BQXSsvA&t=220
- c результатами июльского опроса: Чем ИТ-архитектор занят чаще всего внутри
YouTube
Максим Смирнов — Журнал архитектурных решений
Подробнее о конференции Flow: https://jrg.su/1TyzrD
— —
Планирование сложных изменений в корпоративных информационных системах обычно сопровождалось разработкой и согласованием полноценного описания архитектуры такого изменения. Но рост количества изменений…
— —
Планирование сложных изменений в корпоративных информационных системах обычно сопровождалось разработкой и согласованием полноценного описания архитектуры такого изменения. Но рост количества изменений…
👍29🔥8❤3
Хотел написать недобрый комментарий про новый техрадар https://www.thoughtworks.com/radar Потому подумал, ну что я буду таких уважаемых людей журить. Ну, как вышло у них, так и вышло. Можем кому-то даже понравится
Thoughtworks
Technology Radar | Guide to technology landscape
The Technology Radar is an opinionated guide to today's technology landscape. Read the latest here.
🤔7👍2
📚Меня регулярно журят за то, что часто я размещаю в канале ссылки без своих комментариев. И, в принципе, я согласен, что такой разбор текстов крайне полезен и занимателен. Но есть одна проблема. Если делать это сразу, то большинство может ограничиться прочтением комментария, а не исходного сообщения. Потому попробую провести небольшой эксперимент. Сегодня я размещу ссылку на текст, который три года назад довольно широко разошелся в сети. А после выходных поделюсь своим к нему отношением. Возможно, мы в чем разойдемся, а в чем0то и совпадем. Полезного чтения: 8 Tips to Better Architecture Diagrams
Adam Cogan
8 Tips to Better Architecture Diagrams - Adam Cogan
A good architecture diagram (aka a cloud architecture diagram or system architecture diagram) gives a great overview of your project. It lets you see at a glance what the overall structure of the solution is. This is useful for gaining an understanding of…
👍30❤3👎3
Архитектура ИТ-решений
📚Меня регулярно журят за то, что часто я размещаю в канале ссылки без своих комментариев. И, в принципе, я согласен, что такой разбор текстов крайне полезен и занимателен. Но есть одна проблема. Если делать это сразу, то большинство может ограничиться прочтением…
Возможно, вы решите, что я стану ругать этот текст. Вовсе нет. Это один из лучших текстов в бесконечной веренице десятков, если не сотен сообщений с заголовком типа: 5 советов по созданию архитектурных диаграмм. Сам стиль пяти, десяти или восьми советов отстойный. И если что и ругать, то именно его. 98% текстов с таким заголовком не содержат ни одной мысли. Одна-две ценные вещи, которые можно вытащить из оставшихся представителей жанра, как например из этого текста, представляют собой редкое исключение.
Потому я не стану цепляться к советам разместить данные сверху или непременно использовать draw.io (я его и так использую), а непосредственно перейду к 1,5 дельным замечаниям (один совет я засчитал за половину, т.к. большую его часть додумал самостоятельно).
Итак, первое, что меня зацепило – это картинка из второго совета, показывающая насколько убого строится диаграмма зависимостей в Visual Studio. Чтоб это стало понятно не нужно много слов. Достаточно просто рядом поместить картинку из ReSharper
Потому я не стану цепляться к советам разместить данные сверху или непременно использовать draw.io (я его и так использую), а непосредственно перейду к 1,5 дельным замечаниям (один совет я засчитал за половину, т.к. большую его часть додумал самостоятельно).
Итак, первое, что меня зацепило – это картинка из второго совета, показывающая насколько убого строится диаграмма зависимостей в Visual Studio. Чтоб это стало понятно не нужно много слов. Достаточно просто рядом поместить картинку из ReSharper
👍9
Архитектура ИТ-решений
📚Меня регулярно журят за то, что часто я размещаю в канале ссылки без своих комментариев. И, в принципе, я согласен, что такой разбор текстов крайне полезен и занимателен. Но есть одна проблема. Если делать это сразу, то большинство может ограничиться прочтением…
Вторая полезная вещь частично навеяна тем же вторым советом, но в большей степени советом номер 3, да и другими советами тоже. И вещь эта в том, что в значительной доле случает ИТ-архитектору придется рисовать диаграммы, описывающие «физическую структуру» решения. Т.е. картинки, отвечающие на вопрос из чего состоит решение, основным элементом которых будут процессы (или системы или pod-ы или вызываемые методы… ). Рисунки из третьего столбца матрицы Захмана, если угодно. Или верхние буквы C из C4 model Саймона Брауна.
И какие бы мысли мы не хотели бы выразить своей диаграммой, воплощать их придется «поверх» вот этих самых контейнерных диаграмм. Поведение поверх стрелок, особенности организации данных поверх вообще всего (компонент, коннекторов и контейнеров). В общем, так или иначе пропитывать диаграмму необходимым нам смыслом. Делать то, что не предусмотрено нотациями моделирования.
Кстати, потому нотации моделирования в нашем деле вещь крайне полезная. Они как губки впитывают в себя все несущественные вещи, которые в своих диаграмма мы хотим спрятать из фигуры в фон.
Спасибо автору исходной заметки и как вам такой формат?
И какие бы мысли мы не хотели бы выразить своей диаграммой, воплощать их придется «поверх» вот этих самых контейнерных диаграмм. Поведение поверх стрелок, особенности организации данных поверх вообще всего (компонент, коннекторов и контейнеров). В общем, так или иначе пропитывать диаграмму необходимым нам смыслом. Делать то, что не предусмотрено нотациями моделирования.
Кстати, потому нотации моделирования в нашем деле вещь крайне полезная. Они как губки впитывают в себя все несущественные вещи, которые в своих диаграмма мы хотим спрятать из фигуры в фон.
Спасибо автору исходной заметки и как вам такой формат?
👍39🔥12❤3👏2
The Open Group решили порадовать нас мультиком про Archimate https://youtu.be/-7UhU4kGRUE?si=WzNlGLGs9IB_wDKW
YouTube
The ArchiMate® Modeling Language
This video is beneficial to those looking to bring the ArchiMate® Modeling Language, from The Open Group ArchiMate® Forum into their organization. This is a high level overview geared towards Executives and those new to the ArchiMate Specification. https…
👍18❤3
Архитектура ИТ-решений
📚Меня регулярно журят за то, что часто я размещаю в канале ссылки без своих комментариев. И, в принципе, я согласен, что такой разбор текстов крайне полезен и занимателен. Но есть одна проблема. Если делать это сразу, то большинство может ограничиться прочтением…
📎 Давайте продолжим этот жанр. Напомню, что сначала я размещаю статью, а на этот раз серию статей Джеймса Хики What Are Domain-Driven Design Aggregates? а через пару дней напишу свой комментарий к этому тексту.
Возможно, наши суждения в чем-то совпадут, ну или дополнят друг друга. Итак, сегодня:
Агрегаты — одна из наиболее неправильно понимаемых концепций в предметно-ориентированном проектировании. Это просто скопление сущностей и объектов? Или что-то большее?
Возможно, наши суждения в чем-то совпадут, ну или дополнят друг друга. Итак, сегодня:
Агрегаты — одна из наиболее неправильно понимаемых концепций в предметно-ориентированном проектировании. Это просто скопление сущностей и объектов? Или что-то большее?
James Hickey
What Are Domain-Driven Design Aggregates?
Aggregates are one of the most misunderstood concepts in domain-driven design. Is it just a clump of entities & objects? Or something more?
👍5
TOGAF Standard, 10th Edition Pocket Guide https://pubs.opengroup.org/pocket-guides/togaf-pocket-guide/main/introduction.html
👍27
Архитектура ИТ-решений
📎 Давайте продолжим этот жанр. Напомню, что сначала я размещаю статью, а на этот раз серию статей Джеймса Хики What Are Domain-Driven Design Aggregates? а через пару дней напишу свой комментарий к этому тексту. Возможно, наши суждения в чем-то совпадут,…
That’s a lot of text to make 2 join tables
- это один из комментариев к исходному тексту. И с ним сложно поспорить. А вот с картинкой в финале этой заметки, на которой Member связывает два Bubbles, можно спорить до бесконечности. Ну, просто любая неоднозначная вещь способна вызвать подобный спор.
Но я не стану за это цепляться потому, что текст мне понравился. Мало кто из тех, кто пишет про DDD рассуждает об агрегатах. А я, как и автор статьи считаю, что это важно. Еще меньше доля среди DDD-писателей тех, кто отважится приводить простые (а значит всегда неоднозначные) примеры. Часто ИТ-авторам не хватает на это… искренности, готовности открыться для потенциального наезда от читателя. И в-третьих, мало кто из авторов простеньких примеров тут же поймает вас на рефлекторном желании «сделать быстро и неправильно». Словно психолог, покажет вам кляксы Роршаха и тут же обвинит вас в том, что вы увидели в них схему реляционной БД. Супер! Среди архитекторов широко известна концепция точки зрения (viewpoint). Но я бы сказал, что автор текста продемонстрировал нам другое. Назову это углом зрения или перспективой – способностью рассмотреть хорошо знакомые вещи некоторым новым способом
В общем, читаем продолжение DDD & Data Modelling: How Do I Persist Aggregates?
- это один из комментариев к исходному тексту. И с ним сложно поспорить. А вот с картинкой в финале этой заметки, на которой Member связывает два Bubbles, можно спорить до бесконечности. Ну, просто любая неоднозначная вещь способна вызвать подобный спор.
Но я не стану за это цепляться потому, что текст мне понравился. Мало кто из тех, кто пишет про DDD рассуждает об агрегатах. А я, как и автор статьи считаю, что это важно. Еще меньше доля среди DDD-писателей тех, кто отважится приводить простые (а значит всегда неоднозначные) примеры. Часто ИТ-авторам не хватает на это… искренности, готовности открыться для потенциального наезда от читателя. И в-третьих, мало кто из авторов простеньких примеров тут же поймает вас на рефлекторном желании «сделать быстро и неправильно». Словно психолог, покажет вам кляксы Роршаха и тут же обвинит вас в том, что вы увидели в них схему реляционной БД. Супер! Среди архитекторов широко известна концепция точки зрения (viewpoint). Но я бы сказал, что автор текста продемонстрировал нам другое. Назову это углом зрения или перспективой – способностью рассмотреть хорошо знакомые вещи некоторым новым способом
В общем, читаем продолжение DDD & Data Modelling: How Do I Persist Aggregates?
James Hickey
DDD & Data Modelling: How Do I Persist Aggregates?
Confused about how to persist DDD aggregates? What are the trade-offs? What are the options to begin with? Does it matter?
👍11
Архитектура ИТ-решений
That’s a lot of text to make 2 join tables - это один из комментариев к исходному тексту. И с ним сложно поспорить. А вот с картинкой в финале этой заметки, на которой Member связывает два Bubbles, можно спорить до бесконечности. Ну, просто любая неоднозначная…
Вторая часть серии, на мой взгляд, оказалась заметно слабее первой. (Может тема такая). Тем не менее, я думаю, что оставшиеся две заметки:
- DDD Aggregates: Consistency Boundary
- DDD Aggregates: Optimistic Concurrency
реабилитируют серию. Рекомендую их посмотреть
- DDD Aggregates: Consistency Boundary
- DDD Aggregates: Optimistic Concurrency
реабилитируют серию. Рекомендую их посмотреть
James Hickey
DDD Aggregates: Consistency Boundary
A consistency boundary helps us when we have business rules in our software that span multiple objects or have high contention. Let's dig down a bit deeper!
👍5👎1🔥1
Архитектура ИТ-решений
🗞 Журнал архитектурных решений Запись моего выступления на конференции бизнес- и системных аналитиков, а немножко и архитекторов Flow2023 https://youtu.be/Qt26BQXSsvA&t=220 - c результатами июльского опроса: Чем ИТ-архитектор занят чаще всего внутри
СлайдыPDF_Журнал_архитектурных_решений.pdf
4.2 MB
А слайды рассказа про Журнал архитектурных решений я так и не выложил. Исправляюсь!
👍12🔥6❤2
В официальном твиттер-аккаунте The Open Group, посвященном ArchiMate, позавчера снова появилась ссылка на кликабельный Language Notation Guide
👍43🤨2
🗿В прогрессе нет ничего неизбежного. Многие плохие идеи, которые были давно и надолго спрятаны, имеют тенденцию возвращаться
Это про монолит, если что. Длинный и довольно красочный текст, с большим количеством ссылок (я знаю, такие многим нравятся), возвращающий нас к неутихающему спору про монолит и микросервисы. Давно не было слышно сторону, голосующую за распределенные системы. Этот текст прерывает молчание. Честно говоря, мне понравилось. За 18 минут свободного блуждания мыслей автора я не встретил тезиса, с которым был бы готов поспорить. Наслаждайтесь! https://mikaelvesavuori.medium.com/on-complexity-and-monoliths-424ea76abaf5
Generated with DALL·E. Prompt: “a complex monolith in a server room, with the faces of IT consultants...
Это про монолит, если что. Длинный и довольно красочный текст, с большим количеством ссылок (я знаю, такие многим нравятся), возвращающий нас к неутихающему спору про монолит и микросервисы. Давно не было слышно сторону, голосующую за распределенные системы. Этот текст прерывает молчание. Честно говоря, мне понравилось. За 18 минут свободного блуждания мыслей автора я не встретил тезиса, с которым был бы готов поспорить. Наслаждайтесь! https://mikaelvesavuori.medium.com/on-complexity-and-monoliths-424ea76abaf5
Generated with DALL·E. Prompt: “a complex monolith in a server room, with the faces of IT consultants...
Medium
On Complexity and Monoliths
Putting microservices (and other architectures) in a realistic light without resurrecting what should stay dead.
👍17👎2🤔1
Mark Richards решил записать видео, в котором перечислил названия фаз TOGAF ADM. TOGAF 10 за 10 минут, так сказать.
Не очень понимаю зачем, ну да ладно https://youtu.be/AihWJ3_klRQ
Не очень понимаю зачем, ну да ладно https://youtu.be/AihWJ3_klRQ
YouTube
Lesson 172 - TOGAF in 10 Minutes
In lesson 156 I gave a brief introduction to the Zachman Framework for enterprise architecture. In this lesson i do the same thing, only this time with TOGAF—The Open Group Architecture Framework. In this lesson I focus mostly on the Architecture Development…
👍3🤔1
Альберто Брандолини пробует пересмотреть метафору технического долга (не в первый раз, кстати; когда-то раньше он говорил о долге перед мафией). Заменить техдолг он предлагает целостным дизайном. Получается, на мой взгляд, не очень убедительно, но задуматься заставляет https://medium.com/@ziobrando/from-technical-debt-to-design-integrity-48e7056b6776
Medium
From Technical Debt to Design Integrity
Despite being widely used in the software development community, I think the technical debt metaphor has been misused, leading to annoying…
Как вам разноцветные цитаты в новой версии telegram? (это был просто вежливый вопрос, отчасти, как я надеюсь, замещающий утреннее приветствие)
А мы возвращаемся к жанру обсуждения околоархитектурных текстов. На этот раз я предлагаю вам вышедший на неделе текст Pierre Pureur и Kurt Bittner Has Your Architectural Decision Record Lost Its Purpose? и обещаю сделать его критический разбор через пару дней. (Я и правда довольно скептично настроен к тому, что пишут обычно эти авторы)
А мы возвращаемся к жанру обсуждения околоархитектурных текстов. На этот раз я предлагаю вам вышедший на неделе текст Pierre Pureur и Kurt Bittner Has Your Architectural Decision Record Lost Its Purpose? и обещаю сделать его критический разбор через пару дней. (Я и правда довольно скептично настроен к тому, что пишут обычно эти авторы)
InfoQ
Has Your Architectural Decision Record Lost Its Purpose?
Architectural Decision Records (ADRs) are important vehicles for communicating the architectural decisions a development team makes about a system. Lacking a clear definition of what is architectural, and also lacking anywhere else to record important decisions…
❤2
Архитектура ИТ-решений
Как вам разноцветные цитаты в новой версии telegram? (это был просто вежливый вопрос, отчасти, как я надеюсь, замещающий утреннее приветствие) А мы возвращаемся к жанру обсуждения околоархитектурных текстов. На этот раз я предлагаю вам вышедший на неделе…
Возможно, я немного предвзято отношусь к авторам этого текста(за исключением, разве что, Thomas Betts). Если кто-то находит их рассуждения полезными и ценными, то просто игнорируйте мои придирки.
Но у меня сложилось впечатление, что Пьер и Курт часто делают примерно так. Сначала они пишут текст с рядом предложений и гипотез. Как, например, в вышедшей полтора года назад статье Software Architecture: It Might Not Be What You Think It Is. Потом они ссылаются на свою же статью, как на некий свершившийся факт, набор принятых, устоявшихся, само собой разумеющихся практик. (Что не всегда так). Так в старой статье предлагается отказаться от взгляда на архитектуру, как на структуру решения и полностью заменить описание архитектуры набором архитектурных решений. А потом, как бы сверху закрытой темы, нам советуют не путать архитектурные решения с другими решениями, важными, но не архитектурными. И архитектуры, в её традиционном виде, уже как бы давно не существует. А вот сейчас, на взгляд авторов, важно не замутить воду настоящих архитектурных решений решениями важными, но не архитектурными
Так и хочется крикнуть, словно вдогонку уносящему авторов поезду:
- Эй, ребята, Мы не с вами! Вы одни, сами с собой уноситесь на этом поезде в страну плюшевых единорогов.
Это у вас там пасутся стада Minimum Viable Architectures (MVA), эволюционирующие вместе со своими продуктами. Это у вас запрещены архитектурные описания в виде документов, а архитектурой занимаются абсолютно все потому, что профессиональные архитекторы давно уволены и т.д.
У нас же сохранились архитекторы и архитектурные описания. И ADRs дополняют их, а не отменяют. И смена языка, на котором пишется приложения, в 99,9% случаев является архитектурно-значимым решениями. И замена одной реляционной базы данных на другую – тоже архитектурное решение. (В тексте это примеры трудно заменяемых, но не архитектурных решений). Думаю, ключевая ошибка авторов в том, что они сводят всю пользу архитектуры исключительно к гарантиям атрибутов качества. Что абсолютно не верно!
В принципе, текст то довольно насыщенный, а порой и интересный. Но разбирать его надо критически, цепляясь буквально за каждую фразу. Вот, например, на мой взгляд нельзя просто так взять и написать:
Architecture, then, establishes limits on the kinds of problems a system can solve, and even, sometimes, on the ability of developers to see different kinds of solutions by establishing a kind of hammer-nail blindness to alternatives.
Ну, т.е. написать можно, но тут же должна набежать толпа архитекторов решений и объяснить авторам, что архитекторы для того и существуют, чтоб помочь увидеть альтернативные решения тем, у кого взгляд почему-то замылился. А еще напомнить, что выбор конкретной реализации всегда лишает нас преимуществ отвергнутых альтернатив. Так что ограничиваем мы не область проблем, а пространство решений. Не потенциально возможных решений, а решений, воплощенных на практике.
В общем, кто еще из нас muddies the waters, такие как я читатели, или же авторы текста – вопрос открытый!
Но у меня сложилось впечатление, что Пьер и Курт часто делают примерно так. Сначала они пишут текст с рядом предложений и гипотез. Как, например, в вышедшей полтора года назад статье Software Architecture: It Might Not Be What You Think It Is. Потом они ссылаются на свою же статью, как на некий свершившийся факт, набор принятых, устоявшихся, само собой разумеющихся практик. (Что не всегда так). Так в старой статье предлагается отказаться от взгляда на архитектуру, как на структуру решения и полностью заменить описание архитектуры набором архитектурных решений. А потом, как бы сверху закрытой темы, нам советуют не путать архитектурные решения с другими решениями, важными, но не архитектурными. И архитектуры, в её традиционном виде, уже как бы давно не существует. А вот сейчас, на взгляд авторов, важно не замутить воду настоящих архитектурных решений решениями важными, но не архитектурными
Так и хочется крикнуть, словно вдогонку уносящему авторов поезду:
- Эй, ребята, Мы не с вами! Вы одни, сами с собой уноситесь на этом поезде в страну плюшевых единорогов.
Это у вас там пасутся стада Minimum Viable Architectures (MVA), эволюционирующие вместе со своими продуктами. Это у вас запрещены архитектурные описания в виде документов, а архитектурой занимаются абсолютно все потому, что профессиональные архитекторы давно уволены и т.д.
У нас же сохранились архитекторы и архитектурные описания. И ADRs дополняют их, а не отменяют. И смена языка, на котором пишется приложения, в 99,9% случаев является архитектурно-значимым решениями. И замена одной реляционной базы данных на другую – тоже архитектурное решение. (В тексте это примеры трудно заменяемых, но не архитектурных решений). Думаю, ключевая ошибка авторов в том, что они сводят всю пользу архитектуры исключительно к гарантиям атрибутов качества. Что абсолютно не верно!
В принципе, текст то довольно насыщенный, а порой и интересный. Но разбирать его надо критически, цепляясь буквально за каждую фразу. Вот, например, на мой взгляд нельзя просто так взять и написать:
Architecture, then, establishes limits on the kinds of problems a system can solve, and even, sometimes, on the ability of developers to see different kinds of solutions by establishing a kind of hammer-nail blindness to alternatives.
Ну, т.е. написать можно, но тут же должна набежать толпа архитекторов решений и объяснить авторам, что архитекторы для того и существуют, чтоб помочь увидеть альтернативные решения тем, у кого взгляд почему-то замылился. А еще напомнить, что выбор конкретной реализации всегда лишает нас преимуществ отвергнутых альтернатив. Так что ограничиваем мы не область проблем, а пространство решений. Не потенциально возможных решений, а решений, воплощенных на практике.
В общем, кто еще из нас muddies the waters, такие как я читатели, или же авторы текста – вопрос открытый!
InfoQ
Software Architecture: It Might Not Be What You Think It Is
Software architecture is often a misunderstood idea. Unlike traditional architecture, where the design is separated from construction, in software how something is built influences what is built, and vice versa. Software architecture is about decisions, not…
👍31❤3👎2🤔1
А вот вам старая (8.1.1) зато кликабельная версия и TOGAF ADM. Выбирать можно кружочки на картинке с тогафовской ромашкой слева или закладки справа.
Наслаждайтесь http://www.togaf.com/admref/admreference.html
Наслаждайтесь http://www.togaf.com/admref/admreference.html
🔥23👍14❤5
📚Вчера меня пригласили в книжный клуб Code of Architecture команды Тинькофф.
⏺ Запись уже на YouTube-канале клуба
Я давно хотел поучаствовать в таком разговоре и с удовольствием присоединился к обсуждению первых двух глав книги Continuous Architecture in Practice. Надеюсь, интересно было не только тем кто оказался в кадре, но и тем кто пришел послушать
Я давно хотел поучаствовать в таком разговоре и с удовольствием присоединился к обсуждению первых двух глав книги Continuous Architecture in Practice. Надеюсь, интересно было не только тем кто оказался в кадре, но и тем кто пришел послушать
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Continuous Architecture in Practice — Episode 1
Читаем две первые главы:
- Why Software Architecture Is More Important than Ever
- Architecture in Practice: Essential Activities
Разбираем:
- Что же такое архитектура приложений и почему она настолько важна;
- Какие вызовы стоят перед архитектурой…
- Why Software Architecture Is More Important than Ever
- Architecture in Practice: Essential Activities
Разбираем:
- Что же такое архитектура приложений и почему она настолько важна;
- Какие вызовы стоят перед архитектурой…
🔥41👍15🎉2