Привет, Хабр! Меня зовут Александр Бардаш, я главный архитектор интеграционных платформ в МТС. Сегодня расскажу, почему ИТ-архитекторам важно хотя бы иногда всегда читать книги, и поделюсь подборкой для начинающих. Жду вас под катом и в комментариях!
Архитекторы разные — и литература для них тоже
Начнем с того, что архитекторы бывают абсолютно разные. Например, одни формируют бизнес-процессы, работают с TOGAF и другими паттернами. Эти ребята больше углублены в операционные процессы, чем в технические.
А есть архитектура уровня solution. Это когда архитектор вместе с командой может набросать общий план и подытожить, соответствует ли он концепту компании, не противоречит ли требованиям архитектора более высокого уровня. Такой архитектор распределяет взаимодействие между всеми командами, сохраняя при этом основные принципы.
Еще есть системные, инфраструктурные архитекторы и так далее. Все они отвечают за конкретные области.
У каждого своя специфика, поэтому советовать книги для всех архитекторов в целом — не совсем корректно. Но у меня есть подборка из пяти книг, которая подойдет тем, кто хочет расти в ИТ-архитектуре, — те самые основы из основ. На практике читать, конечно, придется намного больше.
5 книг для начинающих архитекторов
А вот и моя «базовая» подборка:
«Паттерны объектно-ориентированного проектирования», Ральф Джонсон, Джон Влиссидес, Ричард Хелм, Эрих Гамма.
«Микросервисы. Паттерны разработки и рефакторинга», Крис Ричардсон.
«Паттерны разработки на Python. TDD, DDD и событийно-ориентированная архитектура», Гарри Персиваль и Боб Грегори.
Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture, Tomasz Jaskula.
Cloud Native Microservices With Kubernetes: A Comprehensive Guide to Building, Scaling, Deploying, Observing, and Managing Highly-Available Microservices in Kubernetes, Aymen El Amri.
Дальше расскажу, чем мне нравится каждая из них.
«Паттерны объектно-ориентированного проектирования», Р. Джонсон, Дж. Влиссидес, Р. Хелм, Э. Гамма
И сразу приятная новость: есть хороший перевод. А еще сразу предупрежу: в книге даются примеры кода на C++, и это может напугать. Советую не поддаваться порыву отложить ее до лучших времен, потому что ребята рассказывают все достаточно просто и текст в принципе нацелен на понимание.
С момента выхода первого тиража прошло больше 20 лет, и за это время книга стала культовой. В ней описываются паттерны объектно-ориентированного программирования в работе с монолитными решениями и серверами ОА. Их придумали очень давно, и без них никуда не уедешь. Важно понимать, как и почему все это работает.
Книга поможет понять роли паттернов в архитектуре сложных систем, а еще — создавать собственные приложения с учетом ограничений, которые возникают при разработке крупных проектов. Шаблоны в книге взяты из реальных систем и основаны на реальных кейсах.
Если вы нацелены больше на монолитную работу, а значит, должны следить за решениями внутри кода — однозначно рекомендую эту книгу. По сути это и есть системная архитектура.
«Микросервисы. Паттерны разработки и рефакторинга», Крис Ричардсон
В книге описаны 44 паттерна проектирования микросервисных приложений. Она поможет понять, зачем вообще использовать микросервисную архитектуру, как декомпозировать задачу для микросервиса, какого размера он должен быть и так далее. Тут же про управление транзакциями и шаблоны запросов, стратегии тестирования и шаблоны развертывания.
Выдержки из этой книги уже гуляют по русскоязычным форумам. Энтузиасты сами создали подборки: 30 паттернов, 40 паттернов и так далее. Но я рекомендую именно первоисточник.
По промокоду IDKFA в Строках эти книги можно прочитать бесплатно. Активировать промокод — до 30.09.2024.
«Паттерны разработки на Python. TDD, DDD и событийно-ориентированная архитектура», Гарри Персиваль и Боб Грегори
Теория — это классно и здорово, но хороший архитектор должен опробовать свои знания на практике и больше углубиться в процесс работы. Эта книга как раз позволяет ознакомится с TDD, DDD подходами. Все это описано в книге — паттерны можно опробовать и на личном опыте понять, насколько вам удобно с ними работать.
Авторы пишут про:
«инверсию зависимостей» и ее связи с портами и адаптерами,
про паттерны и различия между ними — например, чем отличаются паттерны «Сущность», «Объект-значение» и «Агрегат»;
разделение ответственности на команды и запросы;
событийно-управляемую архитектуру и реактивные расширения.
Отдельно отмечу, что в книге много хороших примеров на Python. Я пользовался ими сам и вам тоже советую.
Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture, Tomasz Jaskula
Многие, услышав «микросервисы», сразу говорят: «Монолит — отстой». Но это неправда, все решения по-своему хороши.
Чтобы действительно понимать это, разбираться в этом и аргументировать свои решения, полезно прочитать эту книгу. Она написана на английском, перевод мне пока не попадался. Но ребята пишут легко и очень классно рассказывают о теме — было интересно читать.
Cloud Native Microservices With Kubernetes, Aymen El Amri
Напоследок одна из топовых книг об инфраструктурной части проектирования систем. Полное название: Cloud Native Microservices With Kubernetes: A Comprehensive Guide to Building, Scaling, Deploying, Observing, and Managing Highly-Available Microservices in Kubernetes.
Мы как архитекторы должны понимать, как приложение работает на уровне инфраструктуры, что такое CI/CD, high-level ability, GitOps и прочее. Об этом тезисно и подробно сказано в книге. Развернуто описаны современные ключевые истории: clinative, cubic architecture, QR компоненты.
Рекомендую эту книгу тем, кто действительно хочет быть многопрофильным архитектором.
Почему вообще нужно читать?
Быть архитектором — это постоянное обучение. Почти как быть программистом. Вот программист, например, выучил C++, но новаторских изменений в нем намного меньше, чем подходов разработки паттернов, фреймворков, технологий и так далее.
Архитектор — это человек, который должен быть в тренде всего и всегда. Чтобы понимать современные решения и разбираться в них, он должен постоянно учиться. Ему важно ориентироваться в выборе технологий, подходов, паттернов, фреймворка – все это может сильно повлиять на процессы компании, на продукт.
Работа архитектора заключается не только в том, чтобы спроектировать классную систему. Еще ее нужно защитить перед Tech Lead разработчиками, которые потом уже будут ее реализовывать. Например, как-то я показывал архитектуру в новой команде и мне сказали: «Да ну, твоя архитектура нам не подходит. Мы всегда работали с монолитами». И вот тогда мне пришлось аргументированно доказывать разработчикам, почему им стоит пользоваться именно моей архитектурой. Я много читал по этому (и не только) поводу — например, ту же Strategic Monoliths and Microservices. Так что мне не составило труда объяснить, почему через пять лет монолит выльется в проблему — даже если разработчики сейчас об этом не думают вообще. Архитектор всегда должен мыслить концептуально и наперед. К слову, убедить разработчиков у меня все-таки получилось.
Но чтобы продать архитектуру разработчикам, нужно сначала продать ее себе. То есть сначала нужно убедить самого себя, что твое решение — качественное и нужное. И сделать это, опять же, намного проще, если у тебя широкий кругозор, ты можешь оценить ситуацию с разных сторон и можешь делать прогнозы. Книги, конечно, в этом очень помогают.
Теперь слово вам! Расскажите в комментариях, какие книги уже читали и как оно. Сейчас я раздумываю над подборкой для уже опытных ИТ-архитекторов, так что скоро продолжим тему.
Комментарии (14)
erogov
03.08.2024 08:14+3СУБД — фундамент любой системы, поэтому: Владимир Комаров, «Путеводитель по базам данных»
rinace
03.08.2024 08:14+2К сожалению , современное поколение разработчиков воспринимает СУБД как хранилище данных. Как работает СУБД они не знают и знать не хотят - "зачем вы используете pg_adviser_lock? У нас Фреймворк такой."
Это не исключение это правило. В ходе решения поставленной задачи по импортозамещению и миграции решений с Oracle на PostgreSQL над особенностями и отличием СУБД они не задумываются , берут Фреймворк и ORM и потом классическое "мы уперлись в СУБД".
Они все такие, решение предоставляются разными подрядчиками , и разными командами разработки . Пока , я не встретил ни одного разработчика прошедшего хотя бы DBA-1. Может, это мне не везет, а может это современный тренд такой .
Итог всегда один - перевод в промышленную эксплуатацию , аварийная ситуация , ответ разработчиков "мы не понимаем, что происходит". Это не гипербола , это прямая цитата с конфколла по ходу решения аварийной ситуации.
Иногда доходит до смешного - подрядчик-поставшик решения объясняет вендору СУБД , что СУБД работает неправильно - "а вот в Oracle блокировки обрабатываются по другому и на старой системе все работало". Это было на самом деле, я лично это слышал.
"У нас проблема с СУБД , очень много ожиданий Client read." - это не шутка это мнение руководителя группы разработки. Пришлось собрать нервы в кулак и очень аккуратно , максимально толерантно объяснять и открывать глаза на картину мира и цитировать RTFM. В свое рабочее время и совершенно бесплатно .
erogov
03.08.2024 08:14+2Увы, увы. Микросервисы да паттерны.
rinace
03.08.2024 08:14Про микросервисы был забавный случай - руководитель разработки гордо рапортует -"мы перевели архитектуру с монолита на микросервисы". Странно , но почему то со стороны СУБД никаких изменений не выполнялось.
Выяснилось они считают отдельным микросервисом - отдельную БД в кластере PostgreSQL.
Какой смысл и выгода от использования отдельной БД в кластере взамен отдельной схемы в одной БД - я пока не понял, хотя особенно данную тему и не копал. Возможно , выгода есть.
Proscrito
03.08.2024 08:14+4А как еще воспринимать субд? Как графический движок, или веб-сервер?
Если разработчик (абсолютно корректно) воспринимает базу данных как... базу данных, это не значит, что он не знает как она работает. Я же, как архитектор, если вижу необходимость в продвинутых дба-скиллах для конкретного проекта, буду просить разрабов с продвинутыми дба-скиллами, либо вообще дедикейтед дба. Но правда в том, что далеко не всегда они нужны. Если вы используете для выполнения задач разрабов с неподходящим набором и уровнем скилов, то скорее всего это не его проблема. Вы ж его наняли для этой работы, как-то тестировали...
Основная идея микросервисов: логическое разделение доменной области и бизнес-логики для создания слабо связанной системы. Пока перед продом не стала реальная задача по отказоустойчивости и масштабированию, вполне допустимо все базы в один кластер сунуть, это ничуть не обесценит архитектуру. Но будет дешевле, что есть козырным аргументом для бизнеса. При необходимости девопс легким движением руки разнесет базы физически, это не потребует глобального рефакторинга. А необходимость может появиться через время после запуска.
mrise
03.08.2024 08:14Я думаю тут вопрос больше не в том, чтобы уметь делать, а в том, чтобы знать, что так можно сделать.
Не "как правильно управлять локами в многопоточной среде", а "локи существуют".
Как разработчик, я не всегда (практически никогда) не могу повлиять на компетенции людей, с которыми приходится работать. Поэтому естественно что мне хочется, чтобы они хотя-бы знали, когда они могут позвать на помощь.
Proscrito
03.08.2024 08:14От бестолковых коллег, да и в принципе от широкого спектра самых разных человеческих ошибок и косяков (после которых люди еще имеют наглость упрекать ии в галлюцинациях...) никто не застрахован. И иногда действительно какие-то качества мешают человеку выявить (или признать) свою некомпетентность в чем-то и вовремя попросить совета-помощи. Ничего не попишешь. Для минимизации вреда и контроля подобного рода ошибок существует культура разработки, со всеми этими код ревью, дейликами и тех. лидами. Но серебряной пули нету, увы.
sunstyle
03.08.2024 08:14Гладко было на бумаге, да забыли про овраги.
В статье перечисляются виды архитекторов, потом даются книги для ИТ-архитектора, которого нет в этих видах.
Затем даются паттерны разработки чведь архитектору надо о них знать". А как насчёт уровней солюшн, корпоративного, неужели нет книг, и достаточно выучить паттерны и работать? Сомнительно, но нет.
olku
03.08.2024 08:14+2Порекомендую Team Topologies чтобы понимать откуда ноги растут или почему отличная архитектура встречает сопротивление в организации.
voldemar_d
03.08.2024 08:14По промокоду IDKFA в Строках эти книги можно прочитать бесплатно
А по коду IDDQD - скачать бесплатно без смс (шутка :)
Вот программист, например, выучил C++, но новаторских изменений в нем намного меньше, чем подходов разработки паттернов, фреймворков, технологий и так далее.
Фраза "выучил C++", подозреваю, относится к не очень большому проценту программистов на нем.
Сравнение количества новаторских изменений в языке с количеством подходов (далее по тексту), имхо, не совсем корректно. И вообще непонятно, что с чем сравнивается. Можно, например, сравнить количество новаторских изменений в C++23 по сравнению с C++98.
AVF_613
03.08.2024 08:14"42" - ответ на главный вопрос жизни, вселенной и всего такого.
С него и начинайте...
стандарты
GERAM
Библиография стандарта
[1] ENV 12204:1996 Перспективные производственные технологии. Системная архитектура. Конструкции для моделирования предприятия (Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling)
[2] ENV 40003:1990 Компьютеризированное интегрированное производство. Системная архитектура. Среда для моделирования предприятия (Computer integrated manufacturing - Systems architecture - Framework for enterprise modeling)
[3] ISO/TR 10314-1:1990 Промышленная автоматизация. Цеховое производство. Часть 1. Эталонная модель для стандартизации и методологии для идентификации требований (Industrial automation - Shop floor production - Part 1: Reference model for standardization and a methodology for identification of requirements)
[4] ISO 14258:1998 Промышленные автоматизированные системы. Концепции и правила для моделей предприятий (Industrial automation systems - Concepts and rules for enterprise models)
[5] ISO/IEC 15288:2002 Системная инженерия. Процессы жизненного цикла систем (Systems engineering - System life cycle processes)
[6] ISO/IEC TR 15504-2:1998 Информационная технология. Оценка программного процесса. Часть 2. Эталонная модель для процессов и возможности процесса (Information technology - Software process assessment - Part 2: A reference model for processes and process capability)
[7] ISO/IEC 15414:2002 Информационная технология. Открытая распределенная обработка. Эталонная модель. Язык предприятия (Information technology - Open distributed processing - Reference model-Enterprise language)
[8] ISO 15531-1:2004 Промышленные автоматизированные системы и интеграция. Управляющие данные о промышленном производстве. Часть 1. Общий обзор (Industrial automation systems and integration - Industrial manufacturing management data - Part 1: General overview)
[9] AMICE, CIMOSA Открытая системная архитектура для компьютеризированного интегрированного производства (Open System Architecture for CIM. 2nd edn. Berlin: Springer-Verlag. ISBN 0 387 56256 7, 1993)
[10] Bernus, P. and Nemes, L Вклад GERAM в консенсус в области интеграции предприятий (The Contribution of GERAM to Consensus in the Area of Enterprise Integration, in Kosanke and Nell, pp. 175-189, 1997)
[11] Bernus, P., et al. eds. Архитектура интеграции предприятий (Architectures for Enterprise Integration. Chapman and Hall, London ISBN 0412 731401, 1996)
[12] Cheim, D. and Doumeingts, G. Эталонная модель GRAI-GIM, архитектура и методология (The GRAI-GIM reference model, architecture and methodology, in Bernus, P., et al., eds., Architectures for Enterprise Integration, Chapman and Hall, London ISBN 0412 73140 1, 1996)
[13] CIMOSA ASSOCIATION, CIMOSA - Открытая системная архитектура для компьютеризированного интегрированного производства (Open System Architecture for CIM: Technical Baseline, Version 3.2, 1963)
[14] Doumeingts, G., Vallespir, B. and Chen, D., Сетка GRAI моделирования решений (Decision modelling GRAI grid, in Bernus, P., Mertins, K. and Schmidt, G., eds. Handbook on architecture for Information Systems, Berlin, Springer-Verlag, 1998)
[15] Kosanke, K. and Nell, J.G. Стандартизация в ИСО для инжиниринга предприятий и интеграции (Standardization in ISO for enterprise engineering and integration, in Computers in Industry, 40 (1999), pp.311-319, Elsevier Science B.V., Amsterdam, 1999)
[16] Kosanke, K. and Nell, J.G., eds., Инжиниринг предприятий и интеграция: нахождение консенсуса на международном уровне (Enterprise Engineering and Integration: Building International Consensus. In: Proceedings of ICEIMT 97, Research Reports Esprit, Berlin, Springer-Verlag, ISBN 3 540 63402 9, 1997)
[17] Kosanke, K., Vernadat, F.B. and Zelm, M., CIMOSA: Эволюция и приложения в сфере инжиниринга предприятий и интеграции (Evolution and Applications in Enterprise Engineering and Integration. Computers in Industry, Elsevier, 1999, vol.40, No.2-3)
[18] Ortiz, A., Lario, F. and Ros, L, Интеграция предприятий - Интеграционный менеджмент бизнес-процессов (Enterprise Integration - Business Process Integrated Management, in Kosanke, K., Vernadat, F.B. and Zelm, M., 1999, pp.311-319)
[19] Petrie, C.J., Jr., ed. Моделирование интеграции предприятий. Тезисы 1-й международной конференции ICEIMT 92 (Enterprise Integration Modelling. Proceedings of the 1st International Conference. MIT Press, Cambridge, MA, ISBN 0 262 66080 6, 1992)
[20] Scheer, A.-W., Инжиниринг бизнес-процессов - Эталонная модель промышленных предприятий (Business Process Engineering - Reference Models for Industrial Enterprises, Berlin, Springer-Verlag, 1994)
[21] Scheer, A.-W, ARIS - Среда бизнес-процессов (Business Process Frameworks. 2nd edn., Berlin, Springer-Verlag. ISBN 3 540 65813, 1999)
[22] Sowa, J.F. and Zachman, J.A., Extending and formalizing the framework for information systems architecture, IBM Systems Journal, 1992, vol.31, No.3 4
[23] Vernadat, F.B., Моделирование предприятий и интеграция - Принципы и приложения (Enterprise Modelling and Integration - Principles and Applications, Chapman and Hall, London, ISBN 0 412 60550 3, 1996)
[24] Williams, T.J., Rathwell, G.A. and Li Hong, eds. Руководство по планированию и применению программ интеграции предприятий (A Handbook on Master Planning and Implementation for Enterprise Integration Programmes. Report 160, Purdue Laboratory for Applied Industrial Control, Purdue University, W. Lafayette, IN, 1996)
rinace
Самая главная книга для начинающего архитектора и вообще IT-специалиста - "Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте" Эдвард Йордан.
Самое удивительное то, что выросло поколение которое повторяет все ошибки описанные и разобранные лет 30 назад. История сделала поворот по спирали.
Всё повторяется - вплоть до прямых цитат : "а на тестовом стенде у нас все работало быстро ".