📝 Где вести API-документацию 📝
Ведение API-документации - это задача аналитиков и разработчиков команды, которая занимается Backend, серверной частью системы.
API-документацию проекта можно поделить на:
✅ публичную,
✅ внутреннюю.
От того, какую документацию надо создавать, будет зависеть выбор конкретного инструмента.
Я подготовила для вас мини-книгу с подборкой инструментов, используемых для документирования API, где рассказала про их преимущества и недостатки.
Ссылки:
🔗 Swagger (в РФ под VPN, но это не проблема для компаний)
🔗 Postman
🔗 Confluence (в РФ под VPN)
🔗 GitHub Pages (инструкция для разработчиков, на англ)
🔗 GitLab Pages (инструкция для разработчиков, на англ)
Мини-книга в слайдах к посту 📝
#RestApiGA
Ведение API-документации - это задача аналитиков и разработчиков команды, которая занимается Backend, серверной частью системы.
API-документацию проекта можно поделить на:
✅ публичную,
✅ внутреннюю.
От того, какую документацию надо создавать, будет зависеть выбор конкретного инструмента.
Я подготовила для вас мини-книгу с подборкой инструментов, используемых для документирования API, где рассказала про их преимущества и недостатки.
Ссылки:
Мини-книга в слайдах к посту 📝
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🔥8❤3👏3
💥📙 Пример API-документации для сервиса #RentACar в Postman 💥📙
(важная ссылка в конце поста👇)
Коллеги, недавно я публиковала пошаговый план проектирования REST API с примером метода создания нового автомобиля через панель администратора.
Теперь я подготовила для вас полную API-документацию для сервиса, включающую все методы CRUD:
+ создание,
+ получение,
+ изменение
+ иудаление
автомобилей, которые будут сдаваться в аренду.
Для создания API-документации я использовала инструмент тестирования и документирования Postman.
Документация сделана в формате для публичного использования.
В ней не описаны алгоритмы работы методов и маппинг данных, но в ней есть описание каждого метода.
Она отлично подойдет для использования разработчиками Frontend (web-приложения администратора).
Обратите внимание на верхнюю панель с настройками:
1. Можно менять площадку Test/Prod.
В зависимости от этого будет меняться URL запросов.
Сейчас документация настроена на Prod.
2. Можно настраивать формат отображения: Single/Double Column.
Это настройка для удобства чтения. Я предпочитаю Single Column.
3. Можно настраивать формат отображения запросов под языки программирования и не только.
Сейчас по умолчанию настроен стандартный формат для документации curl.
По описанию методов есть всё:
✅ Описание метода
✅ Пример запроса
✅ Пример ответа (успех и ошибки, обратите внимание, что справа сверху можно переключать коды ответов)
Всё по настоящему! 🙂
💥💥💥💥💥
Познакомиться с API-документацией RentACar можно по ссылке:
🔗 https://documenter.getpostman.com/view/20545501/2sAY4uBNBF
💥💥💥💥💥
Этот документ может послужить отличным примером для ваших будущих проектов. Сохраняйте в свою коллекцию ценных материалов! 🙌
#RestApiGA
(важная ссылка в конце поста👇)
Коллеги, недавно я публиковала пошаговый план проектирования REST API с примером метода создания нового автомобиля через панель администратора.
Теперь я подготовила для вас полную API-документацию для сервиса, включающую все методы CRUD:
+ создание,
+ получение,
+ изменение
+ иудаление
автомобилей, которые будут сдаваться в аренду.
Для создания API-документации я использовала инструмент тестирования и документирования Postman.
Документация сделана в формате для публичного использования.
В ней не описаны алгоритмы работы методов и маппинг данных, но в ней есть описание каждого метода.
Она отлично подойдет для использования разработчиками Frontend (web-приложения администратора).
Обратите внимание на верхнюю панель с настройками:
1. Можно менять площадку Test/Prod.
В зависимости от этого будет меняться URL запросов.
Сейчас документация настроена на Prod.
2. Можно настраивать формат отображения: Single/Double Column.
Это настройка для удобства чтения. Я предпочитаю Single Column.
3. Можно настраивать формат отображения запросов под языки программирования и не только.
Сейчас по умолчанию настроен стандартный формат для документации curl.
По описанию методов есть всё:
✅ Описание метода
✅ Пример запроса
✅ Пример ответа (успех и ошибки, обратите внимание, что справа сверху можно переключать коды ответов)
Всё по настоящему! 🙂
💥💥💥💥💥
Познакомиться с API-документацией RentACar можно по ссылке:
💥💥💥💥💥
Этот документ может послужить отличным примером для ваших будущих проектов. Сохраняйте в свою коллекцию ценных материалов! 🙌
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥27❤🔥8🤩4❤3
🔎 Что влияет на дизайн REST API метода 🔎
Дизайн REST API (или “контракт REST API”) — это договоренность между разработчиками клиентов (Frontend или другие сервера) и разработчиками сервера (Backend) о том, как будут работать методы REST API.
Он включает в себя полное описание API-методов:
✔️ структуры запроса:
+ Метод (GET, POST, …)
+ URL ресурса
+ Заголовки (headers)
+ Тело запроса (body) в формате JSON (или другом)
✔️ и структуры ответа:
+ Статус-код HTTP
+ Заголовки ответа (headers).
+ Тело ответа в формате JSON (или другом).
Его создают Системные аналитики совместно с Backend-разработчиками.
Что важно знать о влиянии разных частей системы на дизайн REST API методов:
✅ Дай клиенту то, что он хочет
Не усложняйте запросы лишними полями и деталями, которые могут быть в БД, если они не нужны клиенту. REST API должен быть удобен для использования: чем меньше лишних данных, тем проще клиенту обрабатывать ответ.
✅ В БД может быть бардак, а в REST API соберите и структурируйте данные нормально, пожалуйста
Часто внутренняя структура базы данных (БД) не точно соответствует тому, как клиентам удобно получать данные. Это нормально. Задача REST API — преобразовать сложные внутренние данные в понятную, логичную и структурированную форму для внешнего пользователя.
✅ Названия параметров в БД и в REST API не должны соответствовать
То, как называются колонки в базе данных, не всегда понятно для пользователей API. Убедись, что параметры и названия в REST API интуитивно понятны и соответствуют бизнес-логике, а не внутренней реализации системы.
✅ Количество методов REST API не зависит от количества экранов
У нас может быть один экран на фронтенде, который зависит сразу от нескольких API методов. Или наоборот — один метод может обслуживать несколько экранов. Дизайн API должен базироваться на логике данных, а не на количестве пользовательских интерфейсов.
✅ Для асинхронных запросов придется сделать два метода
Иногда вам нужно сначала отправить запрос, который запускает долгую операцию на сервере, а потом — проверить ее статус. Для таких случаев часто используют два метода: один для запуска процесса, другой — для проверки состояния.
✅ Интеграционные API-методы: под вызовом нашего API-метода скрывается вызов чужого API и они не должны совпадать на 100%
Когда наш API вызывает внешние системы, не обязательно транслировать их ответы один в один. Можно обрабатывать и обогащать данные, либо урезать. Главное дать для клиента API полезную и удобную для использования информацию.
✅ Иногда POST будут использовать для получения данных, или вообще для всего - и это “ок”
Хотя по стандарту POST используется для создания данных в БД, бывают случаи, когда его используют для получения или выполнения других операций. Это зависит от архитектуры и бизнес-логики.
✅ Стандартизируйте
Старайтесь сделать единый дизайн запросов и ответов для всех методов по CRUD-модели одной сущности, с учетом исключений для отдельных методов.
И напоследок:
Опыт и взаимодействие команды решают многое. Системные аналитики и разработчики вместе создают API, находя баланс между внутренней сложностью системы и удобством для пользователей.
#RestApiGA
Дизайн REST API (или “контракт REST API”) — это договоренность между разработчиками клиентов (Frontend или другие сервера) и разработчиками сервера (Backend) о том, как будут работать методы REST API.
Он включает в себя полное описание API-методов:
✔️ структуры запроса:
+ Метод (GET, POST, …)
+ URL ресурса
+ Заголовки (headers)
+ Тело запроса (body) в формате JSON (или другом)
✔️ и структуры ответа:
+ Статус-код HTTP
+ Заголовки ответа (headers).
+ Тело ответа в формате JSON (или другом).
Его создают Системные аналитики совместно с Backend-разработчиками.
Что важно знать о влиянии разных частей системы на дизайн REST API методов:
✅ Дай клиенту то, что он хочет
Не усложняйте запросы лишними полями и деталями, которые могут быть в БД, если они не нужны клиенту. REST API должен быть удобен для использования: чем меньше лишних данных, тем проще клиенту обрабатывать ответ.
✅ В БД может быть бардак, а в REST API соберите и структурируйте данные нормально, пожалуйста
Часто внутренняя структура базы данных (БД) не точно соответствует тому, как клиентам удобно получать данные. Это нормально. Задача REST API — преобразовать сложные внутренние данные в понятную, логичную и структурированную форму для внешнего пользователя.
✅ Названия параметров в БД и в REST API не должны соответствовать
То, как называются колонки в базе данных, не всегда понятно для пользователей API. Убедись, что параметры и названия в REST API интуитивно понятны и соответствуют бизнес-логике, а не внутренней реализации системы.
✅ Количество методов REST API не зависит от количества экранов
У нас может быть один экран на фронтенде, который зависит сразу от нескольких API методов. Или наоборот — один метод может обслуживать несколько экранов. Дизайн API должен базироваться на логике данных, а не на количестве пользовательских интерфейсов.
✅ Для асинхронных запросов придется сделать два метода
Иногда вам нужно сначала отправить запрос, который запускает долгую операцию на сервере, а потом — проверить ее статус. Для таких случаев часто используют два метода: один для запуска процесса, другой — для проверки состояния.
✅ Интеграционные API-методы: под вызовом нашего API-метода скрывается вызов чужого API и они не должны совпадать на 100%
Когда наш API вызывает внешние системы, не обязательно транслировать их ответы один в один. Можно обрабатывать и обогащать данные, либо урезать. Главное дать для клиента API полезную и удобную для использования информацию.
✅ Иногда POST будут использовать для получения данных, или вообще для всего - и это “ок”
Хотя по стандарту POST используется для создания данных в БД, бывают случаи, когда его используют для получения или выполнения других операций. Это зависит от архитектуры и бизнес-логики.
✅ Стандартизируйте
Старайтесь сделать единый дизайн запросов и ответов для всех методов по CRUD-модели одной сущности, с учетом исключений для отдельных методов.
И напоследок:
Опыт и взаимодействие команды решают многое. Системные аналитики и разработчики вместе создают API, находя баланс между внутренней сложностью системы и удобством для пользователей.
#RestApiGA
👍32❤1🥰1👏1
GetAnalyst_Тестирование_методов_проекта_RentACar_в_Postman.pdf
31.6 MB
🔥 Рабочий REST API без программирования 🔥
Зачем разрабатывают дизайн REST API (контракты API)?
Контракт REST API означает, что разработчики REST API и его будущие клиенты заранее договорились о том, что API будет работать согласно документации и никак иначе.
👉 Итого: это нужно, чтобы можно было вести параллельную разработку Backend и его клиентов.
Риски такого контрактования до разработки только в том, что пока Backend-разработчики будут писать код, то они могут внести уточнения или сделать что-то не по контракту. Но если команда опытная, то они сводятся к нулю, так как дизайн методов заранее выстраивается с учетом всех нюансов.
В разработке контрактов REST API участвуют Системные аналитики и Backend-разработчики.
И чтобы помочь будущим клиентам API (мобильным и веб-приложениям, другим системам) протестировать работу их кода, можно сделать 👉“API на моках”👈 - тестовый сервер API, который будет работать на основе тестовых данных.
Делать это могут системные аналитики без единой строчки кода!!! Эта функция доступна в Postman - создание mock-сервера (тестового сервера).
Его мы делаем с коллегами как завершающий шаг на программе Дизайн REST API. Осваиваем Postman на максимально продвинутом уровне 🤓
В мини-книге к посту показываю вам пример для проекта #RentACar - тестирование API, работающего на Mock-сервере.
Всю API-документацию и Mock-сервер сделала я, системный аналитик, без программирования.
🔗 Ссылка на API-документацию с указанием Mock-сервера
Книга с инструкцией прикреплена к посту 😎
#RestApiGA
Зачем разрабатывают дизайн REST API (контракты API)?
1. С готовыми контрактами REST API разработчики мобильных и веб-приложений могут начать и завершить разработку раньше, чем Backend-разработчики реально запрограммируют методы.
2. В случае интеграций систем, что часто бывает в проектах банковской сферы, гос проектах и при работе с микросервисами, на стороне системы, которая предоставляет REST API для интеграции может быть готова только API-документация согласно которой ведется разработка. А по факту код по ней еще может быть не написан.
Контракт REST API означает, что разработчики REST API и его будущие клиенты заранее договорились о том, что API будет работать согласно документации и никак иначе.
👉 Итого: это нужно, чтобы можно было вести параллельную разработку Backend и его клиентов.
Риски такого контрактования до разработки только в том, что пока Backend-разработчики будут писать код, то они могут внести уточнения или сделать что-то не по контракту. Но если команда опытная, то они сводятся к нулю, так как дизайн методов заранее выстраивается с учетом всех нюансов.
В разработке контрактов REST API участвуют Системные аналитики и Backend-разработчики.
И чтобы помочь будущим клиентам API (мобильным и веб-приложениям, другим системам) протестировать работу их кода, можно сделать 👉“API на моках”👈 - тестовый сервер API, который будет работать на основе тестовых данных.
Делать это могут системные аналитики без единой строчки кода!!! Эта функция доступна в Postman - создание mock-сервера (тестового сервера).
Его мы делаем с коллегами как завершающий шаг на программе Дизайн REST API. Осваиваем Postman на максимально продвинутом уровне 🤓
В мини-книге к посту показываю вам пример для проекта #RentACar - тестирование API, работающего на Mock-сервере.
Всю API-документацию и Mock-сервер сделала я, системный аналитик, без программирования.
Книга с инструкцией прикреплена к посту 😎
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16❤🔥2❤2👌2👍1
Завтра завершаем запись на открытый урок по Postman.
Если вы планируете развивать свои Hard-skills (твердые навыки) в системном анализе, погружаетесь в Backend-разработку и хотите сделать шаги в создании методов REST API с нуля и научиться вести документацию по ним в Postman, как я показывала на этой неделе (пример Postman-документации), то я рекомендую посетить это занятие!
Открытый урок будет доступен в записи. Вы сможете посмотреть его в удобное время.
📚 Знакомство с REST API через Postman: с нуля до рабочих методов
📅 Доступ 2-4 НОЯБРЯ
🔗 Узнать подробности и зарегистрироваться
План:
1. Самая важная теория по REST API.
2. Знакомство с REST API документацией и принципами её разработки.
3. Практика тестирования API в инструменте Postman.
4. Создание и публикация API-документации через Postman.
5. Постановки задач на Backend-разработчиков.
Подключайтесь с компьютера, смотрите в удобном темпе, выполняйте задания и получайте новые знания на практике 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10👍8🔥6
2️⃣0️⃣0️⃣ HTTP-коды ответов в REST API методах 2️⃣0️⃣0️⃣
HTTP-коды ответов являются неотъемлемой частью структуры ответа REST API. Это стандартизированный способ для сервера сообщить клиенту о результате обработки его запроса.
В разработанной мною API-документации Postman для проекта #RentACar описание ошибок - одна из главных частей документации.
Знание и правильное использование кодов HTTP в ответах REST API методов важно, так как они помогают клиентам понимать, был ли запрос успешен, требует ли действий по исправлению, произошла внутренняя ошибка сервера или пользователю надо показать информацию о совершенной им ошибке. Зависит от ситуации.
Корректное использование кодов ответов также улучшает удобство использования REST API, облегчает отладку в процессе интеграции с вашей системой и улучшает пользовательский опыт. Особенно, если обработка ошибок правильно спроектирована не только с точки зрения правильного выбора кодов ответов, но и с точки зрения проектирования тела ответа (JSON).
❗️HTTP-коды ответов, которые нужно знать❗️
Картинка прикреплена к посту.
+ Коды успеха 200-204е
+ Коды перенаправления 300-е (используются крайне редко, об их существовании просто надо знать)
+ Коды ошибок клиента 400-404е
+ Коды ошибок сервера 500-504е
При проектировании обращайте внимание на то, как будет вести себя REST API с пустыми списками, с завершением пагинации. Это важно для пользовательского опыта.
Например, при возврате пустого списка может использоваться 204 (No Content), или 200 с пустым body, если такое поведение ожидаемо, или 404 Not Found, если отсутствие данных является неожиданным.
Много деталей, которые системные аналитики должны проработать при проектировании логики работы и дизайна каждого REST API метода.
Понимание и правильное применение HTTP-кодов в REST API — важный навык для любого системного аналитика 🚀
#RestApiGA
HTTP-коды ответов являются неотъемлемой частью структуры ответа REST API. Это стандартизированный способ для сервера сообщить клиенту о результате обработки его запроса.
В разработанной мною API-документации Postman для проекта #RentACar описание ошибок - одна из главных частей документации.
Знание и правильное использование кодов HTTP в ответах REST API методов важно, так как они помогают клиентам понимать, был ли запрос успешен, требует ли действий по исправлению, произошла внутренняя ошибка сервера или пользователю надо показать информацию о совершенной им ошибке. Зависит от ситуации.
Корректное использование кодов ответов также улучшает удобство использования REST API, облегчает отладку в процессе интеграции с вашей системой и улучшает пользовательский опыт. Особенно, если обработка ошибок правильно спроектирована не только с точки зрения правильного выбора кодов ответов, но и с точки зрения проектирования тела ответа (JSON).
❗️HTTP-коды ответов, которые нужно знать❗️
Картинка прикреплена к посту.
+ Коды успеха 200-204е
+ Коды перенаправления 300-е (используются крайне редко, об их существовании просто надо знать)
+ Коды ошибок клиента 400-404е
+ Коды ошибок сервера 500-504е
При проектировании обращайте внимание на то, как будет вести себя REST API с пустыми списками, с завершением пагинации. Это важно для пользовательского опыта.
Например, при возврате пустого списка может использоваться 204 (No Content), или 200 с пустым body, если такое поведение ожидаемо, или 404 Not Found, если отсутствие данных является неожиданным.
Много деталей, которые системные аналитики должны проработать при проектировании логики работы и дизайна каждого REST API метода.
Понимание и правильное применение HTTP-кодов в REST API — важный навык для любого системного аналитика 🚀
#RestApiGA
💯17👍10❤6
🎀 GraphQL — знакомство на практике через Postman [пошаговая инструкция] 🎀
Коллеги, опубликовала для вас необычный материал: обучающую статью по знакомству с GraphQL API. Не самый распространенный вид API, но все чаще встречающийся в разработке.
В ней вы найдёте пошаговую инструкцию по тестированию открытого GraphQL API через Postman.
Статья постоена по принципу:
👉 сначала практика -> потом теория.
Материал будет полезен системным аналитикам, которые хотят разобраться в структуре запросов и ответов, понять ключевые принципы работы с GraphQL.
Актуально для тех, кто работает с Backend, Интеграциями и Архитектурой.
Пользуйтесь, делитесь обратной связью и сохраняйте в закладки на будущее 🙂
🔗 Ссылка на статью
Коллеги, опубликовала для вас необычный материал: обучающую статью по знакомству с GraphQL API. Не самый распространенный вид API, но все чаще встречающийся в разработке.
В ней вы найдёте пошаговую инструкцию по тестированию открытого GraphQL API через Postman.
Статья постоена по принципу:
👉 сначала практика -> потом теория.
Материал будет полезен системным аналитикам, которые хотят разобраться в структуре запросов и ответов, понять ключевые принципы работы с GraphQL.
Актуально для тех, кто работает с Backend, Интеграциями и Архитектурой.
Пользуйтесь, делитесь обратной связью и сохраняйте в закладки на будущее 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥42❤11👍3
📄 Шаблон постановки задачи на REST API метод 📄
Структура требований для разработчиков Backend, которую можно использовать в Confluence при описании контрактов REST API методов.
1. Название метода
2. Общее описание
3. Алгоритм работы
4. Пример запроса
5. Пример ответа: успех и ошибки
6. Маппинг данных
7. Дополнительные требования
Аналогичную структуру постановки задачи можно реализовать через инструменты документирования и тестирования API - Postman и Swagger.
Подробнее в статье:
🔗Структура постановки задачи на REST API метод
Также по ней очень удобно делать команды к ChatGPT - это Искусственный Интеллект, который как младший системный аналитик помогает в разработке требований и делает половину работы за вас 🙌
#RestApiGA
Структура требований для разработчиков Backend, которую можно использовать в Confluence при описании контрактов REST API методов.
1. Название метода
2. Общее описание
3. Алгоритм работы
4. Пример запроса
5. Пример ответа: успех и ошибки
6. Маппинг данных
7. Дополнительные требования
Аналогичную структуру постановки задачи можно реализовать через инструменты документирования и тестирования API - Postman и Swagger.
Подробнее в статье:
🔗Структура постановки задачи на REST API метод
Также по ней очень удобно делать команды к ChatGPT - это Искусственный Интеллект, который как младший системный аналитик помогает в разработке требований и делает половину работы за вас 🙌
#RestApiGA
🔥25❤6❤🔥2👍2😁2🤩2
📚 Что почитать и посмотреть по REST API: подборка материалов от GetAnalyst 📚
У нас много новых участников в сообществе 🙌 И…! Вместо того, чтобы рассказывать о себе, я решила сделать для вас подборку из полезных материалов по проектированию REST API. Так вы лучше узнаете меня - Екатерину Ананьеву - не на словах, а на деле 🙂
Материалы расположены по порядку - от простого к сложному. Они помогут вам сделать крутой прорыв в освоении темы и разобраться в сложных вопросах.
(В) Связь базы данных и дизайна REST API
(C) Простыми словами про API
(В) Postman: навык тестирования REST API за вечер
(В) Проект “Система для автосервиса” - видео-обучение.
1. Системный анализ проекта с нуля: Сбор бизнес-требований, погружение в контекст
2. Системный анализ для проекта: определение сущностей и проектирование логической модели БД
3. REST API с нуля: дизайн методов для работы менеджера с заявками автосервиса
(C) Postman: Практическое руководство с примером тестирования открытого API
(С) Postman: Практическое руководство с примером тестирования открытого API - 2.0
(П) Вопросы и ответы по REST API: собеседование на СА
(С) Мини-книга с подробным разбором формата сообщений JSON
(В) Собеседование на СА: разбор задачи на асинхронные запросы в REST API
(C) Структура постановки задачи на REST API метод
(П) gRPС vs REST - что выбрать для проекта
(C) Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)
Также вы можете найти у нас мини-обучения по REST API и практическую программу "Дизайн REST API" для опытных аналитиков.
(В) Видео
(П) Подкасты
(С) Статьи
Делитесь с коллегами, особенно с джунами и мидлами СА!
Сохранили? ❤️
#RestApiGA
У нас много новых участников в сообществе 🙌 И…! Вместо того, чтобы рассказывать о себе, я решила сделать для вас подборку из полезных материалов по проектированию REST API. Так вы лучше узнаете меня - Екатерину Ананьеву - не на словах, а на деле 🙂
Материалы расположены по порядку - от простого к сложному. Они помогут вам сделать крутой прорыв в освоении темы и разобраться в сложных вопросах.
(В) Связь базы данных и дизайна REST API
(C) Простыми словами про API
(В) Postman: навык тестирования REST API за вечер
(В) Проект “Система для автосервиса” - видео-обучение.
1. Системный анализ проекта с нуля: Сбор бизнес-требований, погружение в контекст
2. Системный анализ для проекта: определение сущностей и проектирование логической модели БД
3. REST API с нуля: дизайн методов для работы менеджера с заявками автосервиса
(C) Postman: Практическое руководство с примером тестирования открытого API
(С) Postman: Практическое руководство с примером тестирования открытого API - 2.0
(П) Вопросы и ответы по REST API: собеседование на СА
(С) Мини-книга с подробным разбором формата сообщений JSON
(В) Собеседование на СА: разбор задачи на асинхронные запросы в REST API
(C) Структура постановки задачи на REST API метод
(П) gRPС vs REST - что выбрать для проекта
(C) Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)
Также вы можете найти у нас мини-обучения по REST API и практическую программу "Дизайн REST API" для опытных аналитиков.
(В) Видео
(П) Подкасты
(С) Статьи
Делитесь с коллегами, особенно с джунами и мидлами СА!
Сохранили? ❤️
#RestApiGA
❤48🔥21❤🔥7👍3👌1
🔷 Лайфхаки по поиску работы для аналитиков через LinkedIn 🔷
Поиск работы — важный этап в развитии карьеры, с которым IT-специалисты обычно встречаются каждые 3-5 лет. Делать это можно разными способами, на разных площадках.
Сегодня я хочу рассказать про LinkedIn - профессиональную социальную сеть, на которой вы по сути оформляете свой профиль как резюме. Можно сказать, что это продвинутый аналог hh.ru или Habr-карьеры.
Эта социальная сеть заблокирована в России, но я всё чаще наблюдаю кейсы трудоустройства аналитиков через неё! Поэтому я подготовила для вас статью про лайфхаки поиска работы через LinkedIn.
В ней вы найдёте:
✅ Общую информацию про LinkedIn,
✅ 3 способа поиска работы (третий - самый эффективный),
✅ подборку материалов для подготовки к собеседованиям.
Даже если вы сейчас не ищете работу, рекомендую создать и поддерживать профиль в LinkedIn в актуальном состоянии, чтобы развивать свои профессиональные контакты как в России, так и за её пределами.
Профиль в LinkedIn — это инвестиция в ваш профессиональный рост и личный бренд. Чем больше связей и активности на платформе, тем выше шансы быть замеченным и готовым к следующим карьерным возможностям в будущем 🚀
🔗 Ссылка на статью
Кто уже знаком с соцсетью, поделитесь в комментариях к посту вашим опытом с LinkedIn 🙏
Поиск работы — важный этап в развитии карьеры, с которым IT-специалисты обычно встречаются каждые 3-5 лет. Делать это можно разными способами, на разных площадках.
Сегодня я хочу рассказать про LinkedIn - профессиональную социальную сеть, на которой вы по сути оформляете свой профиль как резюме. Можно сказать, что это продвинутый аналог hh.ru или Habr-карьеры.
Эта социальная сеть заблокирована в России, но я всё чаще наблюдаю кейсы трудоустройства аналитиков через неё! Поэтому я подготовила для вас статью про лайфхаки поиска работы через LinkedIn.
В ней вы найдёте:
✅ Общую информацию про LinkedIn,
✅ 3 способа поиска работы (третий - самый эффективный),
✅ подборку материалов для подготовки к собеседованиям.
Даже если вы сейчас не ищете работу, рекомендую создать и поддерживать профиль в LinkedIn в актуальном состоянии, чтобы развивать свои профессиональные контакты как в России, так и за её пределами.
Профиль в LinkedIn — это инвестиция в ваш профессиональный рост и личный бренд. Чем больше связей и активности на платформе, тем выше шансы быть замеченным и готовым к следующим карьерным возможностям в будущем 🚀
Кто уже знаком с соцсетью, поделитесь в комментариях к посту вашим опытом с LinkedIn 🙏
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥4👍2🦄2
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
🔥🧩 Какие диаграммы нужно знать системному аналитику 🔥🧩
В этом эпизоде мы разберём каждую диаграмму, которую могут использовать в своей работе системные аналитики: что она из себя представляет, когда её применять и с помощью каких инструментов создавать.
Обсудим, стоит ли строго следовать правилам нотаций моделирования, или можно отклоняться от них и создавать свои схемы.
Если вы только начинаете свой путь в системном анализе или уже работаете в этой сфере, этот выпуск будет полезен, чтобы улучшить навыки визуализации и понять, какие диаграммы действительно работают.
🔗 Сайт эпизода с гайдом по диаграммам
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify
Рекомендуем делать заметки в ходе эпизода, чтобы после попробовать новые диаграммы и инструменты в своей работе.
Ставьте реакции, делитесь эпизодом с коллегами и не забывайте сохранять себе полный гайд по диаграммам для СА со страницы эпизода ❤️🔥
В этом эпизоде мы разберём каждую диаграмму, которую могут использовать в своей работе системные аналитики: что она из себя представляет, когда её применять и с помощью каких инструментов создавать.
Обсудим, стоит ли строго следовать правилам нотаций моделирования, или можно отклоняться от них и создавать свои схемы.
Если вы только начинаете свой путь в системном анализе или уже работаете в этой сфере, этот выпуск будет полезен, чтобы улучшить навыки визуализации и понять, какие диаграммы действительно работают.
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify
Рекомендуем делать заметки в ходе эпизода, чтобы после попробовать новые диаграммы и инструменты в своей работе.
Ставьте реакции, делитесь эпизодом с коллегами и не забывайте сохранять себе полный гайд по диаграммам для СА со страницы эпизода ❤️🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22💯6❤2👍2⚡1
GetAnalyst_7_основных_шаблонов_проектирования_архитектуры_для_СА.pdf
5 MB
🔥📚 7 шаблонов проектирования архитектуры, которые важно понимать СА 📚🔥
Системные аналитики (СА) описывают внутреннюю логику работы приложений:
+ связи между данными на пользовательских экранах, в базе данных и API,
+ интеграции с внешними системами,
+ алгоритмы обработки данных,
+ и другие технические детали.
В простых проектах архитектура может не вызывать особых вопросов, так как обычно используется один из вариантов монолитной архитектуры.
А вот в сложных продуктовых компаниях, таких как банки, маркетплейсы и страховые компании, базовых знаний недостаточно. Здесь чаще встречается сложная сервисная (SOA) или микросервисная (MSA) архитектура.
Для таких проектов аналитикам важно понимать архитектуру систем, чтобы грамотно подходить к проектированию новых функций и обеспечивать их корректную интеграцию в существующую инфраструктуру.
👉 Собрала для вас 7 основных шаблонов проектирования архитектуры, которые важно понимать СА.
Рассказала о каждом с примерами и картинками, про связи между ними, и зачем их нужно знать аналитикам.
1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)
Всю информацию собрала в мини-книгу прикрепленную к посту 📚
Загружайте и сохраняйте в личный архив!
#АрхитектураGA
Системные аналитики (СА) описывают внутреннюю логику работы приложений:
+ связи между данными на пользовательских экранах, в базе данных и API,
+ интеграции с внешними системами,
+ алгоритмы обработки данных,
+ и другие технические детали.
В простых проектах архитектура может не вызывать особых вопросов, так как обычно используется один из вариантов монолитной архитектуры.
А вот в сложных продуктовых компаниях, таких как банки, маркетплейсы и страховые компании, базовых знаний недостаточно. Здесь чаще встречается сложная сервисная (SOA) или микросервисная (MSA) архитектура.
Для таких проектов аналитикам важно понимать архитектуру систем, чтобы грамотно подходить к проектированию новых функций и обеспечивать их корректную интеграцию в существующую инфраструктуру.
👉 Собрала для вас 7 основных шаблонов проектирования архитектуры, которые важно понимать СА.
Рассказала о каждом с примерами и картинками, про связи между ними, и зачем их нужно знать аналитикам.
1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)
Всю информацию собрала в мини-книгу прикрепленную к посту 📚
Загружайте и сохраняйте в личный архив!
#АрхитектураGA
🔥45❤10👍6❤🔥4😁2🤔2
👀 Архитектура и Инфраструктура: в чем разница? 👀
Архитектура и инфраструктура в системах — это два взаимосвязанных понятия, которые часто могут путать.
🟢 Архитектура - определяет структуру системы и её ключевые компоненты.
Архитектор или ведущий разработчик выбирает, какие модули или сервисы понадобятся, как они будут взаимодействовать, какие технологии и шаблоны будут использованы для реализации и развития системы. Либо говорит, что проект простой и подойдёт монолит 🙂
Всё, что касается:
относится к архитектуре системы.
🟢 Инфраструктура - обеспечивает физическую и виртуальную основу для работы системы.
Это совокупность аппаратных и программных ресурсов, сетей, систем хранения данных и облачных сервисов, необходимых для работы приложения.
Всё, что касается аппаратного обеспечения:
относится к инфраструктуре.
За это отвечают специалисты инфраструктуры (DevOps-инженеры).
Итого:
И архитектура, и инфраструктура помогают обеспечивать нефункциональные требования к системе, как:
◽️ производительность,
◽️ масштабируемость (прирост большого числа пользователей),
◽️ отказоустойчивость,
◽️ надежность,
◽️ безопасность,
но делают они это с разных сторон:
👉 Архитектура - через распределение логики в разные приложения (сервисы и микросервисы), либо через оптимизацию кодовой базы.
👉 Инфраструктура - отвечает за оборудование, на котором эти приложения работают.
#АрхитектураGA
Архитектура и инфраструктура в системах — это два взаимосвязанных понятия, которые часто могут путать.
🟢 Архитектура - определяет структуру системы и её ключевые компоненты.
Архитектор или ведущий разработчик выбирает, какие модули или сервисы понадобятся, как они будут взаимодействовать, какие технологии и шаблоны будут использованы для реализации и развития системы. Либо говорит, что проект простой и подойдёт монолит 🙂
Всё, что касается:
+ выбора монолитной, сервисной или микросервисной архитектуры,
+ выбора технологий разработки (СУБД, языки программирования, брокеры),
+ выбора API (REST, SOAP, GraphQL и другие),
+ выделение сервисов и микросервисов
,
+ определение количества БД и данных в них,
относится к архитектуре системы.
🟢 Инфраструктура - обеспечивает физическую и виртуальную основу для работы системы.
Это совокупность аппаратных и программных ресурсов, сетей, систем хранения данных и облачных сервисов, необходимых для работы приложения.
Всё, что касается аппаратного обеспечения:
+ количества оперативной памяти и ядер на сервере,
+ одновременного запуска копий приложений на параллельно работающих серверах,
+ резервного копирования,
+ настройки мониторинга,
+ обеспечение безопасности на аппаратном уровне (например, использование VPN),
относится к инфраструктуре.
За это отвечают специалисты инфраструктуры (DevOps-инженеры).
Итого:
И архитектура, и инфраструктура помогают обеспечивать нефункциональные требования к системе, как:
◽️ производительность,
◽️ масштабируемость (прирост большого числа пользователей),
◽️ отказоустойчивость,
◽️ надежность,
◽️ безопасность,
но делают они это с разных сторон:
👉 Архитектура - через распределение логики в разные приложения (сервисы и микросервисы), либо через оптимизацию кодовой базы.
👉 Инфраструктура - отвечает за оборудование, на котором эти приложения работают.
#АрхитектураGA
🔥26💯4❤3👌3👍1
👩🌾 Новый проект: микросервисная архитектура для маркетплейса фермеров #FarmFreshGA 👩🌾
Сухая теория не запоминается. Поэтому каждый месяц я запускаю в канале новый проект, чтобы мы вместе могли разбирать теорию и сразу применять её на практике.
👉 В этом месяце мы проектируем микросервисную архитектуру FarmFresh.
FarmFresh — маркетплейс для локальных фермеров, где можно продавать продукты напрямую покупателям и предлагать подписки на свежие товары.
Основные функции платформы:
✔️ Каталог продуктов — фермеры добавляют товары, а покупатели выбирают и покупают их.
✔️ Подписка на свежие продукты — регулярная доставка с ферм (еженедельно, ежемесячно и т.д.).
✔️ Разовые заказы и просмотр истории покупок.
✔️ Учет остатков и управление доставкой для фермеров с оповещением покупателей о статусах.
✔️ Настройка зон доставки с возможностью указания радиуса и времени.
✔️ Рейтинги и отзывы на продукты.
✔️ Чат поддержки от владельцев маркетплейса для помощи покупателям и фермерам.
✔️ Маркетинговые инструменты: купоны на скидки, акции на товары.
Для пользователей будут разработаны приложения на iOS, Android и Web. Для фермеров также. А панель администратора поможет тех. поддержке управлять всей системой.
📋 План работы:
1. Наглядно разобрать отличия в видах архитектуры: монолит, сервисы и микросервисы.
2. Выделить ключевые микросервисы.
3. Определить API (REST, gRPC, GraphQL и другие) для проекта.
4. Познакомиться с асинхронным взаимодействием и брокерами.
5. Создать схему архитектуры в нотации C4.
Чтобы участвовать в проекте, нужно просто быть подписанным на канал и следить за обновлениями 🙂
Добро пожаловать в новый проект! 🚀
#АрхитектураGA #FarmFreshGA
Сухая теория не запоминается. Поэтому каждый месяц я запускаю в канале новый проект, чтобы мы вместе могли разбирать теорию и сразу применять её на практике.
👉 В этом месяце мы проектируем микросервисную архитектуру FarmFresh.
FarmFresh — маркетплейс для локальных фермеров, где можно продавать продукты напрямую покупателям и предлагать подписки на свежие товары.
Основные функции платформы:
✔️ Каталог продуктов — фермеры добавляют товары, а покупатели выбирают и покупают их.
✔️ Подписка на свежие продукты — регулярная доставка с ферм (еженедельно, ежемесячно и т.д.).
✔️ Разовые заказы и просмотр истории покупок.
✔️ Учет остатков и управление доставкой для фермеров с оповещением покупателей о статусах.
✔️ Настройка зон доставки с возможностью указания радиуса и времени.
✔️ Рейтинги и отзывы на продукты.
✔️ Чат поддержки от владельцев маркетплейса для помощи покупателям и фермерам.
✔️ Маркетинговые инструменты: купоны на скидки, акции на товары.
Для пользователей будут разработаны приложения на iOS, Android и Web. Для фермеров также. А панель администратора поможет тех. поддержке управлять всей системой.
📋 План работы:
1. Наглядно разобрать отличия в видах архитектуры: монолит, сервисы и микросервисы.
2. Выделить ключевые микросервисы.
3. Определить API (REST, gRPC, GraphQL и другие) для проекта.
4. Познакомиться с асинхронным взаимодействием и брокерами.
5. Создать схему архитектуры в нотации C4.
Чтобы участвовать в проекте, нужно просто быть подписанным на канал и следить за обновлениями 🙂
Добро пожаловать в новый проект! 🚀
#АрхитектураGA #FarmFreshGA
🔥100👍20❤10🥰1
🍏 Что такое компоненты системы и как показать его на схеме архитектуры? 🍏
Компонент — это отдельная, функционально законченная часть системы, которая выполняет определённые задачи и обладает собственным интерфейсом для взаимодействия с другими частями системы или пользователями.
В качестве интерфейсов могут выступать UI (User Interface) или API (Application Programming Interface).
Компоненты системы можно поделить на несколько основных групп:
➕ Frontend / UI - приложения с пользовательским интерфейсом.
> iOS, Android и Web FarmFresh для покупателя (3 отдельных компонента)
> iOS, Android и Web FFFermer для фермеров
> Admin FarmFresh - приложение для администраторов и сотрудников маркетплейса
➕ Backend / API - серверные приложения со своей логикой и API для взаимодействия с ними. Сюда относятся сервисы, микросервисы, API-Gateway и другие компоненты.
> Сервис каталога товаров с его REST API, по которому с ним будут взаимодействовать для получения списка товаров, их поиска
> Сервис платежей с его REST API, по которому с ним будут взаимодействовать сервисы заказов и подписок
➕ БД - базы данных, такие как PostgreSQL, Oracle и ФХ - файловые хранилища.
> БД сервиса каталога с товарами, PostgreSQL
> ФХ для хранения картинок товаров.
➕Системы обмена сообщениями - очереди MQ / брокеры сообщений, такие как RabbitMQ, Kafka и другие.
> Очередь для обработки запросов на рассылку SMS-уведомлений, RabbitMQ
Компоненты выделяют в процессе проектирования архитектуры систем и отражают на схеме архитектуры.
Схема архитектуры может быть визуализирована в:
✔️Геометрические фигуры (прямоугольники, стрелки, облака, своим студентам даю спец. нотацию CR, которую можно использовать в их проектах).
✔️Нотация C4 - идеально, когда нужна чисто техническая архитектура.
✔️Archimate - очень связана с бизнес-контекстом.
Другие нотации моделирования можно посмотреть в этой статье.
В рамках дальнейшей работы над проектом FarmFresh мы будем использовать нотации CR и C4.
#АрхитектураGA #FarmFreshGA
Компонент — это отдельная, функционально законченная часть системы, которая выполняет определённые задачи и обладает собственным интерфейсом для взаимодействия с другими частями системы или пользователями.
В качестве интерфейсов могут выступать UI (User Interface) или API (Application Programming Interface).
Компоненты системы можно поделить на несколько основных групп:
➕ Frontend / UI - приложения с пользовательским интерфейсом.
> iOS, Android и Web FarmFresh для покупателя (3 отдельных компонента)
> iOS, Android и Web FFFermer для фермеров
> Admin FarmFresh - приложение для администраторов и сотрудников маркетплейса
➕ Backend / API - серверные приложения со своей логикой и API для взаимодействия с ними. Сюда относятся сервисы, микросервисы, API-Gateway и другие компоненты.
> Сервис каталога товаров с его REST API, по которому с ним будут взаимодействовать для получения списка товаров, их поиска
> Сервис платежей с его REST API, по которому с ним будут взаимодействовать сервисы заказов и подписок
➕ БД - базы данных, такие как PostgreSQL, Oracle и ФХ - файловые хранилища.
> БД сервиса каталога с товарами, PostgreSQL
> ФХ для хранения картинок товаров.
➕Системы обмена сообщениями - очереди MQ / брокеры сообщений, такие как RabbitMQ, Kafka и другие.
> Очередь для обработки запросов на рассылку SMS-уведомлений, RabbitMQ
Компоненты выделяют в процессе проектирования архитектуры систем и отражают на схеме архитектуры.
Схема архитектуры может быть визуализирована в:
✔️Геометрические фигуры (прямоугольники, стрелки, облака, своим студентам даю спец. нотацию CR, которую можно использовать в их проектах).
✔️Нотация C4 - идеально, когда нужна чисто техническая архитектура.
✔️Archimate - очень связана с бизнес-контекстом.
Другие нотации моделирования можно посмотреть в этой статье.
В рамках дальнейшей работы над проектом FarmFresh мы будем использовать нотации CR и C4.
#АрхитектураGA #FarmFreshGA
🔥21👍10❤6❤🔥2
⭐️ Онлайн-практикум по миграциям в БД [18 ноября - ПН] ⭐️
С этого года я провожу дополнительное обучение по БД и SQL для разбора сложных задач, которые выходят за пределы базовых знаний, и помогают в ежедневной работе по развитию систем.
Тема, которую буду разбирать в следующий понедельник, связана с миграциями данных как внутри одной БД, так и между разными БД и СУБД.
👉 Миграция в контексте БД это:
1. Доработка таблиц БД - добавление новых таблиц или полей, их изменение в существующей БД.
2. Перенос данных из одной БД в другую - например, при проектировании микросервисной архитектуры.
Цель - показать, как доработки БД могут влиять на релизы функциональности, научить выстраивать последовательность обновлений базы и показать, на что обращать внимание при переезде с одной СУБД на другую.
📚 Разработка требований к миграциям БД
🗓 18 Ноября в 19:00 Мск
📌 План:
1. Определение понятия миграции данных. Примеры.
2. Требования к обратной совместимости данных. Распространенные ошибки.
3. Влияние нефункциональных требований на миграции в БД.
4. Практика проектирования миграций внутри одной БД.
5. Обзор проблем миграций данных между разными СУБД. Практика.
6. Обзор шаблона постановки задачи на разработчиков по миграции данных.
Проект: БД системы страховой компании.
👉 Практикум проводится в рамках подписки на практикумы по БД и SQL.
Участие в занятии актуально для аналитиков, кто уже знаком с проектированием БД и хочет погружаться в работу с более сложными задачами👀
С этого года я провожу дополнительное обучение по БД и SQL для разбора сложных задач, которые выходят за пределы базовых знаний, и помогают в ежедневной работе по развитию систем.
Тема, которую буду разбирать в следующий понедельник, связана с миграциями данных как внутри одной БД, так и между разными БД и СУБД.
👉 Миграция в контексте БД это:
1. Доработка таблиц БД - добавление новых таблиц или полей, их изменение в существующей БД.
2. Перенос данных из одной БД в другую - например, при проектировании микросервисной архитектуры.
Цель - показать, как доработки БД могут влиять на релизы функциональности, научить выстраивать последовательность обновлений базы и показать, на что обращать внимание при переезде с одной СУБД на другую.
📚 Разработка требований к миграциям БД
🗓 18 Ноября в 19:00 Мск
📌 План:
1. Определение понятия миграции данных. Примеры.
2. Требования к обратной совместимости данных. Распространенные ошибки.
3. Влияние нефункциональных требований на миграции в БД.
4. Практика проектирования миграций внутри одной БД.
5. Обзор проблем миграций данных между разными СУБД. Практика.
6. Обзор шаблона постановки задачи на разработчиков по миграции данных.
Проект: БД системы страховой компании.
👉 Практикум проводится в рамках подписки на практикумы по БД и SQL.
Участие в занятии актуально для аналитиков, кто уже знаком с проектированием БД и хочет погружаться в работу с более сложными задачами
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤1
Термин "масштабироваться" относится к способности системы адаптироваться к изменяющемуся количеству функций в ней или запросов от пользователей: увеличение или уменьшение ресурсов и мощностей для обеспечения эффективной работы.
Масштабирование может быть вертикальным или горизонтальным.
⭐ Вертикальное масштабирование (scaling up/down) означает добавление ресурсов к одному серверу или экземпляру приложения. Например, увеличение объёма оперативной памяти, мощности процессора или места на диске.
Это сравнимо с переездом из маленькой квартиры в большую: вы получаете больше места и ресурсов для своих нужд.
👉 Вертикальное масштабирование имеет свои ограничения, связанные с максимально доступными ресурсами оборудования - нельзя бесконечно добавлять память и ядра процессора.
⭐ Горизонтальное масштабирование (scaling out/in) подразумевает добавление дополнительных экземпляров серверов или приложений, работающих параллельно, для распределения нагрузки. Т.е. запускаются одинаковые копии приложений.
Это можно сравнить с созданием сети из множества магазинов, каждый из которых обслуживает своих клиентов: если один магазин переполнен, клиенты могут перейти в другой.
👉 Горизонтальное масштабирование обычно предпочтительнее, так как оно обеспечивает более высокую доступность и устойчивость к отказам.
➡️ Эти определения важно знать при работе с архитектурой систем, чтобы понимать, почему выбирают микросервисы вместо монолита.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21❤1
📚 Подборка книг про архитектуру и микросервисы 📚
Когда я только начала знакомиться с архитектурой, то одной из первых и любимых книг сразу стала:
📚 Domain Driven Design. Предметно-ориентированное проектирование, Эрик Эванс
Благодаря ей я, как системный аналитик, еще раз пересмотрела подходы к проектированию и описанию требований, структурировала знания, и начала осознанно использовать рекомендации из нее.
Особенно она помогла в подходах к определению сервисов и микросервисов системы, границ их функциональности.
В дополнение к ней я бы хотела порекомендовать:
📚 Release it! Проектирование и зайн ПО для тех, кому не все равно, Майкл Нейгард (тоже мой фаворит!)
📚 Создание микросервисов, Сэм Ньюмен
📚 Микросервисы. Паттерны разработки и рефакторинга, Крис Ричардсон
📚 Высконагруженные приложения, Мартин Клеппман
📚 Чистая архитектура. Искусство разработки программного обеспечения, Роберт Мартин
📚 Эволюционная Архитектура, Нил Форд, Ребекка Парсонс, Патрик Куа
📚 DDD - предметно ориентированное проектирование, Влад Хононов
Новогодние каникулы скоро, будет время на полезное чтение 🎄
Сохраняйте подборку и делитесь другими крутыми книгами для системных аналитиков в комментариях! 🙂
#АрхитектураGA
Когда я только начала знакомиться с архитектурой, то одной из первых и любимых книг сразу стала:
📚 Domain Driven Design. Предметно-ориентированное проектирование, Эрик Эванс
Благодаря ей я, как системный аналитик, еще раз пересмотрела подходы к проектированию и описанию требований, структурировала знания, и начала осознанно использовать рекомендации из нее.
Особенно она помогла в подходах к определению сервисов и микросервисов системы, границ их функциональности.
В дополнение к ней я бы хотела порекомендовать:
📚 Release it! Проектирование и зайн ПО для тех, кому не все равно, Майкл Нейгард (тоже мой фаворит!)
📚 Создание микросервисов, Сэм Ньюмен
📚 Микросервисы. Паттерны разработки и рефакторинга, Крис Ричардсон
📚 Высконагруженные приложения, Мартин Клеппман
📚 Чистая архитектура. Искусство разработки программного обеспечения, Роберт Мартин
📚 Эволюционная Архитектура, Нил Форд, Ребекка Парсонс, Патрик Куа
📚 DDD - предметно ориентированное проектирование, Влад Хононов
Новогодние каникулы скоро, будет время на полезное чтение 🎄
Сохраняйте подборку и делитесь другими крутыми книгами для системных аналитиков в комментариях! 🙂
#АрхитектураGA
❤🔥43👍12