Довольно неплохое руководство по архитектурным ролям для чайников от Adrian Kearns. С картинками, всё как мы любим. https://morphological.wordpress.com/2017/01/26/the-laymans-guide-to-it-architecture-roles/
Peruse Muse Infuse
The Layman’s Guide to IT Architecture Roles
Most roles within information technology are fairly well understood and defined but this can’t always be said of architects. This can be a problem for anyone considering a career progression into …
Почти off-topic: Во вторник Мартин Фаулер опубликовал у себя новый текст Advocate, educator, and authorial stance. Текст полезный и, как это нынче принято у известных архитекторов, больше про тексты, истории, навыки коммуникаций (см., об этом например здесь 2021 Architecture Katas Presentation про нарративы, экспозиции и кульминации или эту серию заметок в блоге Gregor Hohpe). В общем, Мартин в том же ключе, но по делу
Единственно, о чем стоит предупредить. В конце текста (в footnotes) Фаулер не смог удержаться от величайшего спойлера всех времен и народов. Если вы не знакомы с пьесой нобелевского лауреата Сэмюэля Беккета «В ожидании Годо», то лучше не долистывайте текст Мартина до конца
Единственно, о чем стоит предупредить. В конце текста (в footnotes) Фаулер не смог удержаться от величайшего спойлера всех времен и народов. Если вы не знакомы с пьесой нобелевского лауреата Сэмюэля Беккета «В ожидании Годо», то лучше не долистывайте текст Мартина до конца
martinfowler.com
Advocate, educator, and authorial stance
I like to describe a new technique as an educator (rather than advocate) by taking a trade-offs or merits stance.
Я перевез блог https://mxsmirnov.com/ на новый хостинг, а домен к новому регистратору.
Некоторое время ничего не работало, но теперь, надеюсь, всё восстановилось! Если вдруг увидите ошибки или недочеты, то обязательно сообщайте.
Спасибо!
Некоторое время ничего не работало, но теперь, надеюсь, всё восстановилось! Если вдруг увидите ошибки или недочеты, то обязательно сообщайте.
Спасибо!
Думаю, многие уже видели эту заметку. Поделюсь для тех, кто не видел или пропустил: https://vladmihalcea.com/maximum-database-connections/
Vlad Mihalcea
Maximum number of database connections - Vlad Mihalcea
Learn what limits the number of database connections, no matter if you're using Oracle, SQL Server, PostgreSQL, or MySQL.
Новая(июньская) заметка Brian Tucker https://www.ivarjacobson.com/publications/blog/nature-portfolios-portfolio-kanban-alternative-scenarios в длинном сериале статей On The Nature Of Portfolios на сайте IvarJacobson.com Речь как всегда про SAFe Portfolio Kanban (картинка вверху). В общем, для тех, кому интересны виды деятельности за границами одного спринта
А вот и очередная статья из серии А вдруг вам не нужны микросервисы? You Don’t Need Microservices. Ну, правда! Может быть в приложении нет ни одной функции для которой требовалось бы независимое масштабирование. Или же локализация отказов вам не нужна, потому что всё написано хорошо и ничего никогда не сломается. Да и вообще, слишком обширный выбор языков программирования и технологий увеличивает фрагментацию и усложняет тех.стек. Да и независимое развертывание – одни лишние хлопоты.
Написавший эту стать. Мэтью Спенс - большой молодец! Он скрупулёзно перечислил в своем тексте преимущества микросервисов и по каждому задался вопросом: а оно вам действительно надо?
Именно так и следует писать популярные тексты. Тем более что заканчивается автор совершенно внятными тезисами о том, что противопоставление монолита и микросервисов является ложным, а выбор степени изоляции обработчиков событий, команд и запросов можно делать хоть на уровне каждой отдельной функций. Но кто же станет читать правильные слова, не обернутые мишурой ложных дихотомий, ведь правда!?
Написавший эту стать. Мэтью Спенс - большой молодец! Он скрупулёзно перечислил в своем тексте преимущества микросервисов и по каждому задался вопросом: а оно вам действительно надо?
Именно так и следует писать популярные тексты. Тем более что заканчивается автор совершенно внятными тезисами о том, что противопоставление монолита и микросервисов является ложным, а выбор степени изоляции обработчиков событий, команд и запросов можно делать хоть на уровне каждой отдельной функций. Но кто же станет читать правильные слова, не обернутые мишурой ложных дихотомий, ведь правда!?
Medium
You Don’t Need Microservices
Microservices are very much in vogue for web software architecture. For most teams though, the monolith should remain the default choice.
📖 Метод QUERY возможно появится в протоколе HTTP. (Драфтом IETF RFC поделился Ivan Begtin в своем telegram-канале ). Мотивация такого расширения протокола достаточно очевидна. Так же, как и метод GET, новый метод QUERY будет безопасным и идемпотентным. Однако параметры запроса будут передаваться не в строке, а в теле запроса. Собственно, возможные ограничения длины адресной строки и были основной причиной использования для передачи запросов метода POST, который изначально был придуман для публикации команд.
Драфт RFC предусматривает два варианта ответа.
Подробности: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
Драфт RFC предусматривает два варианта ответа.
Direct Response
вернет результаты на ваш запрос в теле ответа. Indirect Response
вернет 303 код, расшифровываемый как See Other
, и гиперссылку в параметре Location
по которой можно будет запросить результаты обработки запроса методом GET.Подробности: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
Telegram
Ivan Begtin
Тем временем, буквально недавно, в июле, появилось предложение по изменению в стандарт HTTP добавлением типа запроса QUERY для запросов в базы данных [1] [2] нечто что имеет самое непосредственное отношение к современным базам данных, индексированию веб сайтов…
Ещё один лонгрид с описанием хорошо нам известных трех архитектурных ролей: https://medium.com/@briqi/the-software-architecture-roles-3bfccc9e36d2 Автор обещает целую серию под общим заголовком Intuitive Software Architecture. Посмотрим, что получится. Начало, вроде бы, неплохое
Наверное, это лучший обзор от Мэтта МакЛарти https://www.infoq.com/articles/overcoming-restlessness/ o REST API и появившихся уже после REST протоколах. Ну и банальный вывод: для разных задач нужны разные протоколы и способы взаимодействия (Все нужные ссылки, включая post-REST внутри текста )
InfoQ
Overcoming RESTlessness
New API protocols like GraphQL, gRPC, and Apache Kafka have risen in popularity as alternatives to REST-inspired HTTP APIs. Instead of seeking to replace REST, the software engineering industry should seek to evolve by building on the maturity of the REST…
fig3-architects-divided-lg.jpg
119.1 KB
А у меня для вас снова ссылка об архитектурных ролях: Enterprise-Solution-Technical, с описанием ответственности, видов работ и результатов деятельности https://www.bcs.org/articles-opinion-and-research/systems-architecture-the-3-basic-types/ (Не стал сжимать картинку. Её и так сложно рассматривать)
Zachman1992.jpg
1.7 MB
Многие идеи, лежащие в основе архитектуры предприятия, выросли из двух статьей Дж.Захмана 1987 и 1992 года. В дальнейшем они были двадцать раз переформулированы и рассеянны по TOGAF-ам, Archimate-ам и прочим источникам (см. «метамодель» Zachman выше).
Короткую заметку Объясняем матрицу Захмана, с первой порцией этих идей, я написал четыре года назад. А вот продолжение, в большей степени про идеи из второй статьи Extending and formalizing the framework for information systems architecture, все обещаю, но никак не напишу. Надеюсь, что многим уже надоело ждать, а это отличный повод самим полистать оригинал
А свой текст я постараюсь написать в начале сентября, по возвращении с коротких каникул!
Короткую заметку Объясняем матрицу Захмана, с первой порцией этих идей, я написал четыре года назад. А вот продолжение, в большей степени про идеи из второй статьи Extending and formalizing the framework for information systems architecture, все обещаю, но никак не напишу. Надеюсь, что многим уже надоело ждать, а это отличный повод самим полистать оригинал
А свой текст я постараюсь написать в начале сентября, по возвращении с коротких каникул!
Новый сезон этого канала я начну с опросов. Конечно, настоящий опрос должен состоять, как минимум, из нескольких пунктов, а его результаты показывать корреляцию между выбранными вариантами ответов. Примерно, как в книге Ускоряйся! Наука DevOps (Accelerate: The Science of Lean Software and DevOps). Но мои задачи немного скромнее. Мне нужно подготовиться к выступлению на ArchDays 2022. Потому и вопросы у меня будут попроще и касаться описания архитектуры ИТ-решения. Их будет несколько. Сегодня первый
Что точно должно быть в описании архитектуры (множественный выбор)
Final Results
10%
Диаграмма маркетиктуры
38%
Architecture decision records
80%
Общий обзор решения(vision), декомпозиция решения на системы и модули
23%
Спецификации API
47%
Описание интеграционных сценариев
31%
Диаграммы последовательности (sequence)
25%
Диаграмма классов или ERD (диаграмма «сущность-связь»)
44%
Обзор требований
33%
Диаграмма развертывания
63%
Обоснование архитектуры
Продолжаем. Чего точно НЕ должно быть в описании архитектуры (множественный выбор)
Final Results
47%
Диаграммы маркетиктуры
6%
Architecture decision records
2%
Общего обзора решения(vision), декомпозиции решения на системы и модули
53%
Спецификаций API
13%
Описания интеграционных сценариев
20%
Диаграмм последовательности (sequence)
36%
Диаграмм классов и ERD (диаграммы «сущность-связь»)
19%
Обзора требований
19%
Диаграммы развертывания
5%
Обоснования архитектуры
Поговорили вчера о диаграммах как код и архитектуре как код https://youtu.be/_EaIHuRWshI
YouTube
Архитектура, диаграммы и код
Как-то раньше мне не попадался блог Wix Engineering, например статья Event Driven Architecture — 5 Pitfalls to Avoid - вполне внятная история о том, что за все хорошее придется платить. Часто совершая ошибки, ну или, как минимум, усложняя решение
Medium
Event Driven Architecture — 5 Pitfalls to Avoid
5 pitfalls that Wix engineers have encountered and fixed during their migration of more than 2000 microservices to Event Driven…
Просто не могу не поделиться новой заметкой от нашего любимого автора шаблонов интеграции Gregor Hohpe. Почему все так знакомо? https://architectelevator.com/transformation/constraint-advantage/
The Architect Elevator
Every Constraint is an Opportunity
You can make transformation lemonade from organizational lemons–sweetened up with the right dose of creativity.