Библиотека Системного Аналитика
Мартин Фаулер. UML. Основы.pdf
📚 Подборка книг по UML на русском языке
1️⃣ Мартин Фаулер. UML. Основы.
Совсем небольшая книга, написана простым языком. Подходит для новичков в UML.
2️⃣ Буч Грэди. Язык UML. Руководство пользователя.
Более подробная чем первая, тоже подходит для новичков.
3️⃣ Дж. Шмуллер. Освой самостоятельно UML за 24 часа.
За 24 часа, конечно, вряд ли освоите, но азы в этом книге растолкованы неплохо.
4️⃣ Крэг Ларман. Применение UML и шаблонов проектирования.
В книге основной упор делается на объектно-ориентированный анализ и проектирование. UML является лишь удобным дополняющим инструментом. Для более продвинутых пользователей.
5️⃣ Джим Арлоу. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование. Книга посвящена использованию UML в связке с RUP. Вы узнаете о роли моделирования в цикле разработки ПО, и эти знания помогут вам ответить на вопрос: как и когда использовать (или не использовать) UML, чтобы найти оптимальное решение для своего проекта. Авторы приводят множество примеров и дают рекомендации по разработке моделей.
6️⃣ М. Блаха. UML 2.0 Объектно-ориентированное моделирование и разработка. Книга помогает научиться мыслить в глобальном понимании проектирования любого приложения, от самого высокого уровня абстракции и до момента написания кода. Книга написана подробно (иногда чересчур) и доступно, особенно раздел, посвященный моделированию. Благодаря сквозному примеру, можно связать все модели логически, что облегчает понимание.
7️⃣ Александр Леоненков. Самоучитель UML. Можно использовать в качестве полного справочника по UML. Для новичков может быть избыточная информация, редко встречающееся на практике.
Скачать можно все книги из поста выше.
🏴☠️ опять напиратили
#проектирование #uml
1️⃣ Мартин Фаулер. UML. Основы.
Совсем небольшая книга, написана простым языком. Подходит для новичков в UML.
2️⃣ Буч Грэди. Язык UML. Руководство пользователя.
Более подробная чем первая, тоже подходит для новичков.
3️⃣ Дж. Шмуллер. Освой самостоятельно UML за 24 часа.
За 24 часа, конечно, вряд ли освоите, но азы в этом книге растолкованы неплохо.
4️⃣ Крэг Ларман. Применение UML и шаблонов проектирования.
В книге основной упор делается на объектно-ориентированный анализ и проектирование. UML является лишь удобным дополняющим инструментом. Для более продвинутых пользователей.
5️⃣ Джим Арлоу. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование. Книга посвящена использованию UML в связке с RUP. Вы узнаете о роли моделирования в цикле разработки ПО, и эти знания помогут вам ответить на вопрос: как и когда использовать (или не использовать) UML, чтобы найти оптимальное решение для своего проекта. Авторы приводят множество примеров и дают рекомендации по разработке моделей.
6️⃣ М. Блаха. UML 2.0 Объектно-ориентированное моделирование и разработка. Книга помогает научиться мыслить в глобальном понимании проектирования любого приложения, от самого высокого уровня абстракции и до момента написания кода. Книга написана подробно (иногда чересчур) и доступно, особенно раздел, посвященный моделированию. Благодаря сквозному примеру, можно связать все модели логически, что облегчает понимание.
7️⃣ Александр Леоненков. Самоучитель UML. Можно использовать в качестве полного справочника по UML. Для новичков может быть избыточная информация, редко встречающееся на практике.
Скачать можно все книги из поста выше.
#проектирование #uml
🔥28👍7❤4
🔐 Авторизация и аутентификация. Обзор
Авторизация и аутентификация — это два разных, но тесно связанных процесса, которые обеспечивают безопасность и доступность данных и ресурсов в системе.
🆔 Идентификация — это процесс установления личности пользователя, то есть получение его идентификатора, такого как логин, email, номер телефона и т.д. Идентификация является первым шагом аутентификации, так как без нее система не знает, с кем имеет дело.
🔑 Аутентификация — это проверка подлинности личности пользователя, то есть подтверждение того, что он является тем, кем себя представляет.
🔐 Авторизация — это определение прав пользователя на доступ к определенным данным и ресурсам в системе, то есть установление того, что он может делать после аутентификации.
Пример: когда Вася хочет войти в конфлюэнс и вводит свою почту, система понимает, что аккаунт с таким email существует. Это идентификация. Затем система отправляет на Васин номер СМС с одноразовым паролем, а Вася вводит пароль и тем самым доказывает, что это именно он. Это аутентификация. Система понимает, что Вася настоящий и перенаправляет его на главную страницу – это авторизация, ведь Вася авторизован (то есть имеет право) на чтение главной страницы, как и любой другой сотрудник.
Способы аутентификации
🔗 OAuth 2.0 — это протокол авторизации, предназначенный для организации доступа клиента к ресурсам или данным на другом сервисе. После выполнения процедуры входа клиент получает от сервера
Напрямую возвращать токен владельцу после успешного входа на сервер OAuth 2 небезопасно. Вместо этого возвращается access_token, который затем обменивается на JWT-токен.
📜 JWT (JSON Web Token) – это открытый стандарт для создания и передачи данных в формате JSON, которые могут быть подписаны и/или зашифрованы. Поскольку информация конфиденциальна, такой токен хранится обычно несколько минут.
JWT состоит из трёх частей: заголовка, полезной нагрузки, подписи. Получив JWT от пользователя, приложение сравнивает секретный ключ с тем значением, которое было передано в токене. Если эти значения не совпадут, значит доверять ему приложение не будет.
🔑 API-ключи – это ключи шифрования для аутентификации пользователя в системе, по аналогии логина и пароля. Ключ обычно передается в заголовке или параметре запроса.
Существует два вида ключей API:
1. Публичный ключ (открытый). Используется для шифрования данных при обращении приложения к серверу.
2. Секретный ключ (закрытый). Известен только пользователю и владельцу сайта. Используется для расшифровки данных, отправленных приложением.
API-ключи применяются при ассиметричном шифровании. Такое шифрование обеспечивает большую безопасность: если злоумышленник получит публичный ключ, то все равно не сможет пройти аутентификацию без секретного ключа.
🔒 mTLS (mutual TLS) — это расширение протокола TLS, которое позволяет обеим сторонам взаимодействия (клиенту и серверу) аутентифицировать друг друга с помощью цифровых сертификатов. Это повышает уровень безопасности и доверия между сторонами, так как исключает возможность подмены или перехвата данных. mTLS часто используется для аутентификации между микросервисами или API.
Есть две пары сертификатов и два закрытых ключа.
1-й закрытый ключ находится на сервере и позволяет расшифровывать данные, которые шифруются открытым ключом, как при обычной работе TLS.
2-й закрытый ключ устанавливается на клиенте, а сервер при ответах клиенту также шифрует данные его открытым ключом. Таким образом, к серверу могут обращаться только те клиенты, у которых есть закрытый ключ для расшифровки данных.
Это не полный перечень всех способов, будем делать отдельные подборки про SSO, SAML, OpenID Connect.
Подборка материалов в следующем посте ➡️
#архитектура #безопасность
Авторизация и аутентификация — это два разных, но тесно связанных процесса, которые обеспечивают безопасность и доступность данных и ресурсов в системе.
🆔 Идентификация — это процесс установления личности пользователя, то есть получение его идентификатора, такого как логин, email, номер телефона и т.д. Идентификация является первым шагом аутентификации, так как без нее система не знает, с кем имеет дело.
🔑 Аутентификация — это проверка подлинности личности пользователя, то есть подтверждение того, что он является тем, кем себя представляет.
🔐 Авторизация — это определение прав пользователя на доступ к определенным данным и ресурсам в системе, то есть установление того, что он может делать после аутентификации.
Пример: когда Вася хочет войти в конфлюэнс и вводит свою почту, система понимает, что аккаунт с таким email существует. Это идентификация. Затем система отправляет на Васин номер СМС с одноразовым паролем, а Вася вводит пароль и тем самым доказывает, что это именно он. Это аутентификация. Система понимает, что Вася настоящий и перенаправляет его на главную страницу – это авторизация, ведь Вася авторизован (то есть имеет право) на чтение главной страницы, как и любой другой сотрудник.
Способы аутентификации
🔗 OAuth 2.0 — это протокол авторизации, предназначенный для организации доступа клиента к ресурсам или данным на другом сервисе. После выполнения процедуры входа клиент получает от сервера
access_token, который позволяет клиентскому приложению получать доступ к ресурсу для выполнения определенных действий от имени пользователя и refresh_token – необходимый для обновления access_token. refresh_token обычно имеет длительный срок действия (исчисляется в месяцах) и обменивается на новый по истечению срока действия. Напрямую возвращать токен владельцу после успешного входа на сервер OAuth 2 небезопасно. Вместо этого возвращается access_token, который затем обменивается на JWT-токен.
📜 JWT (JSON Web Token) – это открытый стандарт для создания и передачи данных в формате JSON, которые могут быть подписаны и/или зашифрованы. Поскольку информация конфиденциальна, такой токен хранится обычно несколько минут.
JWT состоит из трёх частей: заголовка, полезной нагрузки, подписи. Получив JWT от пользователя, приложение сравнивает секретный ключ с тем значением, которое было передано в токене. Если эти значения не совпадут, значит доверять ему приложение не будет.
🔑 API-ключи – это ключи шифрования для аутентификации пользователя в системе, по аналогии логина и пароля. Ключ обычно передается в заголовке или параметре запроса.
Существует два вида ключей API:
1. Публичный ключ (открытый). Используется для шифрования данных при обращении приложения к серверу.
2. Секретный ключ (закрытый). Известен только пользователю и владельцу сайта. Используется для расшифровки данных, отправленных приложением.
API-ключи применяются при ассиметричном шифровании. Такое шифрование обеспечивает большую безопасность: если злоумышленник получит публичный ключ, то все равно не сможет пройти аутентификацию без секретного ключа.
🔒 mTLS (mutual TLS) — это расширение протокола TLS, которое позволяет обеим сторонам взаимодействия (клиенту и серверу) аутентифицировать друг друга с помощью цифровых сертификатов. Это повышает уровень безопасности и доверия между сторонами, так как исключает возможность подмены или перехвата данных. mTLS часто используется для аутентификации между микросервисами или API.
Есть две пары сертификатов и два закрытых ключа.
1-й закрытый ключ находится на сервере и позволяет расшифровывать данные, которые шифруются открытым ключом, как при обычной работе TLS.
2-й закрытый ключ устанавливается на клиенте, а сервер при ответах клиенту также шифрует данные его открытым ключом. Таким образом, к серверу могут обращаться только те клиенты, у которых есть закрытый ключ для расшифровки данных.
Это не полный перечень всех способов, будем делать отдельные подборки про SSO, SAML, OpenID Connect.
Подборка материалов в следующем посте ➡️
#архитектура #безопасность
👍50🔥25❤7
Forwarded from Библиотека Системного Аналитика
Guide_to_the_Systems_Engineering_Body_of_Knowledge_v2.9.pdf
35.2 MB
SEBoK — свод знаний по системной инженерии
Все знают про существование BABOK для бизнес-аналитиков, но не каждый знает, что и системные аналитики тоже имеют собственный свод знаний — SEBoK.
К сожалению, нам не удалось найти полноценный перевод на русский за исключением нескольких статей на Хабре.
SEBoK регулярно обновляется, последняя версия выпущена 20 ноября 2023 г. Изменения можно отслеживать на официальном сайте, там же можно почитать свод знаний в формате вики-страниц.
#свод_знаний
Все знают про существование BABOK для бизнес-аналитиков, но не каждый знает, что и системные аналитики тоже имеют собственный свод знаний — SEBoK.
К сожалению, нам не удалось найти полноценный перевод на русский за исключением нескольких статей на Хабре.
SEBoK регулярно обновляется, последняя версия выпущена 20 ноября 2023 г. Изменения можно отслеживать на официальном сайте, там же можно почитать свод знаний в формате вики-страниц.
#свод_знаний
🔥29👍7❤1
По сети разлетелся пример того, как Zoom AI Companion составляет тестовое содержание встреч. Если это не фейк, то вещь незаменимая
👍15🔥7😁5
SSO
SSO (Single Sign-On) – это технология, которая позволяет пользователю войти в несколько систем без повторной аутентификации.
Например, пользователь входит в систему под своей корпоративной учёткой. Далее он может открывать портал компании, Confluence, Zoom, Outlook, Office – и ему не придётся проходить аутентификацию в каждом приложении по отдельности.
Как работает SSO
1️⃣ Когда пользователь входит в приложение, генерируется SSO-токен и отправляется запрос на аутентификацию в службу SSO.
2️⃣ Сервис проверяет, был ли пользователь ранее аутентифицирован в системе. Если да, он отправляет приложению ответ с подтверждением аутентификации, чтобы предоставить пользователю доступ.
3️⃣ Если у пользователя нет подтвержденного аккаунта, служба SSO перенаправляет пользователя в центральную систему входа (в нашем примере – аутентификация в ОС) и предлагает ему ввести имя пользователя и пароль.
4️⃣ После отправки сервис проверяет учетные данные пользователя и отправляет положительный ответ приложению.
5️⃣ В противном случае пользователь получает сообщение об ошибке и должен повторно ввести учетные данные. Многочисленные неудачные попытки входа в систему могут привести к тому, что сервис заблокирует пользователя от дальнейших попыток на определенный период времени.
Протоколы для SSO
🔸 SAML — это протокол аутентификации, основанный на языке XML. Веб-приложения используют SAML, чтобы передавать аутентификационные данные между сторонами процесса: а именно, между системой управления доступами и провайдером услуг.
🔹 OAuth 2.0 – это протокол авторизации, который позволяет приложениям получать доступ к информации пользователя с других сайтов, не сообщая ему пароль. Вместо постоянного использования паролей, приложения используют токены для доступа к данным данным.
OpenID Connect
OAuth 2.0 разработан только для авторизации — для предоставления доступа к данным и функциям от одного приложения другому.
OpenID Connect (OIDC) — это слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись.
🆚 OAuth VS SAML
OAuth и SAML — это протоколы, используемые для предоставления доступа. Но есть радикальное отличие между ними — SAML для аутентификации, а OAuth для авторизации.
✅ Преимущества SSO
💩 Удобство: пользователь не тратит время и силы на запоминание, ввод или восстановление множества аккаунтов.
💩 Безопасность: пользователь может использовать один сильный пароль, который не хранится и не передается. Токены имеют ограниченный срок действия и могут быть отозваны.
💩 Управление: администратор может централизованно управлять учетными записями, ролями, правами и активностью пользователей, а также интегрировать новые приложения или сайты в систему SSO.
⛔️ Недостатки SSO
💩 Сложность: реализация и поддержка SSO требует дополнительных затрат и ресурсов, таких как разработка, настройка, совместимость и безопасность разных компонентов системы.
💩 Зависимость: если центральный сервер SSO выходит из строя, то все приложения, которые используют SSO, тоже падают. Также, если пользователь теряет свой логин или пароль от центрального сервера, то он теряет доступ ко всем приложениям.
💩 Приватность: пользователь может не захотеть делиться своей личной информацией с разными приложениями, которые используют SSO.
🔹 Наши подборки
Авторизация и аутентификация:
обзор + подборка материалов
📄 Статьи
1. Как работает single sign-on (технология единого входа)?
2. Технология единого входа: как работает SSO
3. Реализация SSO через SAML с примером
4. OpenID Connect (OIDC): Как получить токен?
5. Иллюстрированное руководство по OAuth и OpenID Connect
6. Как работает OAuth 2.0 и OpenID Connect
7. SAML простыми словами
8. Статьи про Keycloak: 1 и 2
9. SSO на микросервисной архитектуре. Используем Keycloak
⏯ Видео
1. SSO — три заветные буквы MustHave в любой архитектуре. Илья Волынкин. ArchDays 2022
2. Проектирование логики аутентификации и авторизации: cookies, JWT, SSO, OAuth 2.0
3. SSO на базе OpenId Connect в корпоративной системе
4. Технология SSO на примере SAML
5. SSO за 13 минут
#архитектура #проектирование
SSO (Single Sign-On) – это технология, которая позволяет пользователю войти в несколько систем без повторной аутентификации.
Например, пользователь входит в систему под своей корпоративной учёткой. Далее он может открывать портал компании, Confluence, Zoom, Outlook, Office – и ему не придётся проходить аутентификацию в каждом приложении по отдельности.
Как работает SSO
1️⃣ Когда пользователь входит в приложение, генерируется SSO-токен и отправляется запрос на аутентификацию в службу SSO.
2️⃣ Сервис проверяет, был ли пользователь ранее аутентифицирован в системе. Если да, он отправляет приложению ответ с подтверждением аутентификации, чтобы предоставить пользователю доступ.
3️⃣ Если у пользователя нет подтвержденного аккаунта, служба SSO перенаправляет пользователя в центральную систему входа (в нашем примере – аутентификация в ОС) и предлагает ему ввести имя пользователя и пароль.
4️⃣ После отправки сервис проверяет учетные данные пользователя и отправляет положительный ответ приложению.
5️⃣ В противном случае пользователь получает сообщение об ошибке и должен повторно ввести учетные данные. Многочисленные неудачные попытки входа в систему могут привести к тому, что сервис заблокирует пользователя от дальнейших попыток на определенный период времени.
Протоколы для SSO
🔸 SAML — это протокол аутентификации, основанный на языке XML. Веб-приложения используют SAML, чтобы передавать аутентификационные данные между сторонами процесса: а именно, между системой управления доступами и провайдером услуг.
🔹 OAuth 2.0 – это протокол авторизации, который позволяет приложениям получать доступ к информации пользователя с других сайтов, не сообщая ему пароль. Вместо постоянного использования паролей, приложения используют токены для доступа к данным данным.
OpenID Connect
OAuth 2.0 разработан только для авторизации — для предоставления доступа к данным и функциям от одного приложения другому.
OpenID Connect (OIDC) — это слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись.
🆚 OAuth VS SAML
OAuth и SAML — это протоколы, используемые для предоставления доступа. Но есть радикальное отличие между ними — SAML для аутентификации, а OAuth для авторизации.
✅ Преимущества SSO
⛔️ Недостатки SSO
Авторизация и аутентификация:
обзор + подборка материалов
📄 Статьи
1. Как работает single sign-on (технология единого входа)?
2. Технология единого входа: как работает SSO
3. Реализация SSO через SAML с примером
4. OpenID Connect (OIDC): Как получить токен?
5. Иллюстрированное руководство по OAuth и OpenID Connect
6. Как работает OAuth 2.0 и OpenID Connect
7. SAML простыми словами
8. Статьи про Keycloak: 1 и 2
9. SSO на микросервисной архитектуре. Используем Keycloak
1. SSO — три заветные буквы MustHave в любой архитектуре. Илья Волынкин. ArchDays 2022
2. Проектирование логики аутентификации и авторизации: cookies, JWT, SSO, OAuth 2.0
3. SSO на базе OpenId Connect в корпоративной системе
4. Технология SSO на примере SAML
5. SSO за 13 минут
#архитектура #проектирование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍34🔥14❤5
💠 Декомпозиция требований и задач
Декомпозиция требований — разбиение хотелок бизнеса на более конкретные и понятные задачи, которые можно передавать в разработку. Декомпозиция позволяет лучше понимать дальнейшие шаги по реализации, правильно расставить приоритеты и точнее давать оценку по срокам вывода функционала. Когда функционал разбивается на части и реализуется последовательно, это позволяет быстрее получить обратную связь от заказчика и сохранить гибкость к изменениям, а также быстрее вывести рабочий функционал. В общем, понятнее, что разрабатывать и рисков меньше.
Горизонтальная и вертикальная декомпозиция
При горизонтальной декомпозиции задачи делятся по типам работ, по уровням или по компонентам. Например, одна задача идет в бэк, вторая во фронт, а третья приводит к изменениям в базе данных. Главный минус: готовый функционал можно получить только после выполнения всех задач.
Вертикальная декомпозиция означает, что результат каждой задачи должен быть логически завершенным и работающим функционалом, который можно показать заказчику.
Методы декомпозиции
1️⃣ Несколько потребностей: задача делится по союзам «и», «или». Например, «сделать заказ и оплатить картой или бонусами» разбивается на три подзадачи.
2️⃣ Сценарии использования: задача делится по основному и альтернативным путям. Например, «купить товар» разбивается на подзадачи «сравнить товары», «добавить в избранное», «узнать о наличии» и т.д.
3️⃣ Разбиение по позитивным и негативным сценариям: по ожидаемому и неожиданному поведению функционала. Например, «совершить покупку по карте» разбивается на подзадачи «совершить покупку без ошибок», «обработать ошибку при недостатке средств на карте», «обработать ошибку при блокировке учетной записи» и т.д.
4️⃣ Разбиение по этапам процесса: по последовательным шагам, которые составляют процесс. Например, «совершить покупку в интернет магазине» разбивается на подзадачи «войти в личный кабинет», «просмотреть товары в корзине», «сформировать счет на оплату» и т.д.
5️⃣ От простого к сложному: по уровню сложности функционала. Например, «сделать баннер» разбивается на подзадачи «показать одну картинку», «сделать сетку из картинок», «сделать карусель из картинок» и т.д.
6️⃣ Операции (CRUD): задача делится по операциям создания, чтения, обновления и удаления. Например, «оформить заказ» разбивается на подзадачи «создать заказ», «просмотреть заказ», «редактировать заказ» и «удалить заказ».
7️⃣ Варианты интерфейса: по поддержке разных языков, устройств, браузеров и т.д. Например, «сделать сайт мультиязычным» разбивается на подзадачи «сделать русскоязычную версию», «сделать англоязычную версию» и т.д.
8️⃣ Разбиение по типам платформы/ОС. Например, «оплатить покупку» разбивается на подзадачи «оплатить покупку на ПК», «оплатить покупку на планшете», «оплатить покупку на смартфоне» и т.д.
9️⃣ Разделение по ролям. Например, «сделать сайт» разбивается на подзадачи «сделать сайт для анонимных пользователей», «сделать сайт для авторизованных пользователей», «сделать бэкофис для пользователей колл-центра» и т.д.
🔟 Разбиение по типам данных и параметрам: по разным типам данных или параметрам, которые функционал должен обрабатывать. Например, «поиск товаров» разбивается на подзадачи «поиск по тексту», «поиск по коду», «поиск по регулярным выражениям» и т.д.
📄 Статьи
1. 8 методов декомпозиции задач
2. Паттерны декомпозиции User Story / задач (из России с VPN)
3. Как справиться с декомпозицией задач и не перестараться + видео
4. Story Mapping на примере пиццерии
5. SPIDR — пять простых техник для создания идеально разделенной пользовательской истории
6. Разбиение пользовательских историй – метод гамбургера
⏯ Видео
1. Декомпозиция задач и аналитик — Михаил Максимов
2. Как мы разбирали слона. Целые, сломанные и лишние детали — доклад Алексея Козлова на конференции Analyst Days-7
3. User Story Splitting: как и зачем добавлять детали пользовательским историям — Юрий Куприянов
4. Использование Use case и User story для декомпозиции задач — Михаил Максимов
5. Плейлист про декомпозицию задач
#требования
Декомпозиция требований — разбиение хотелок бизнеса на более конкретные и понятные задачи, которые можно передавать в разработку. Декомпозиция позволяет лучше понимать дальнейшие шаги по реализации, правильно расставить приоритеты и точнее давать оценку по срокам вывода функционала. Когда функционал разбивается на части и реализуется последовательно, это позволяет быстрее получить обратную связь от заказчика и сохранить гибкость к изменениям, а также быстрее вывести рабочий функционал. В общем, понятнее, что разрабатывать и рисков меньше.
Горизонтальная и вертикальная декомпозиция
При горизонтальной декомпозиции задачи делятся по типам работ, по уровням или по компонентам. Например, одна задача идет в бэк, вторая во фронт, а третья приводит к изменениям в базе данных. Главный минус: готовый функционал можно получить только после выполнения всех задач.
Вертикальная декомпозиция означает, что результат каждой задачи должен быть логически завершенным и работающим функционалом, который можно показать заказчику.
Методы декомпозиции
1️⃣ Несколько потребностей: задача делится по союзам «и», «или». Например, «сделать заказ и оплатить картой или бонусами» разбивается на три подзадачи.
2️⃣ Сценарии использования: задача делится по основному и альтернативным путям. Например, «купить товар» разбивается на подзадачи «сравнить товары», «добавить в избранное», «узнать о наличии» и т.д.
3️⃣ Разбиение по позитивным и негативным сценариям: по ожидаемому и неожиданному поведению функционала. Например, «совершить покупку по карте» разбивается на подзадачи «совершить покупку без ошибок», «обработать ошибку при недостатке средств на карте», «обработать ошибку при блокировке учетной записи» и т.д.
4️⃣ Разбиение по этапам процесса: по последовательным шагам, которые составляют процесс. Например, «совершить покупку в интернет магазине» разбивается на подзадачи «войти в личный кабинет», «просмотреть товары в корзине», «сформировать счет на оплату» и т.д.
5️⃣ От простого к сложному: по уровню сложности функционала. Например, «сделать баннер» разбивается на подзадачи «показать одну картинку», «сделать сетку из картинок», «сделать карусель из картинок» и т.д.
6️⃣ Операции (CRUD): задача делится по операциям создания, чтения, обновления и удаления. Например, «оформить заказ» разбивается на подзадачи «создать заказ», «просмотреть заказ», «редактировать заказ» и «удалить заказ».
7️⃣ Варианты интерфейса: по поддержке разных языков, устройств, браузеров и т.д. Например, «сделать сайт мультиязычным» разбивается на подзадачи «сделать русскоязычную версию», «сделать англоязычную версию» и т.д.
8️⃣ Разбиение по типам платформы/ОС. Например, «оплатить покупку» разбивается на подзадачи «оплатить покупку на ПК», «оплатить покупку на планшете», «оплатить покупку на смартфоне» и т.д.
9️⃣ Разделение по ролям. Например, «сделать сайт» разбивается на подзадачи «сделать сайт для анонимных пользователей», «сделать сайт для авторизованных пользователей», «сделать бэкофис для пользователей колл-центра» и т.д.
🔟 Разбиение по типам данных и параметрам: по разным типам данных или параметрам, которые функционал должен обрабатывать. Например, «поиск товаров» разбивается на подзадачи «поиск по тексту», «поиск по коду», «поиск по регулярным выражениям» и т.д.
📄 Статьи
1. 8 методов декомпозиции задач
2. Паттерны декомпозиции User Story / задач (из России с VPN)
3. Как справиться с декомпозицией задач и не перестараться + видео
4. Story Mapping на примере пиццерии
5. SPIDR — пять простых техник для создания идеально разделенной пользовательской истории
6. Разбиение пользовательских историй – метод гамбургера
1. Декомпозиция задач и аналитик — Михаил Максимов
2. Как мы разбирали слона. Целые, сломанные и лишние детали — доклад Алексея Козлова на конференции Analyst Days-7
3. User Story Splitting: как и зачем добавлять детали пользовательским историям — Юрий Куприянов
4. Использование Use case и User story для декомпозиции задач — Михаил Максимов
5. Плейлист про декомпозицию задач
#требования
Please open Telegram to view this post
VIEW IN TELEGRAM
👍36🔥23❤8👏1🥱1
Важно ли аналитику уметь программировать?
По определению, аналитик не разработчик, поэтому уметь програмиировать он не должен. А вот понимать, что такое код и как он пишется — должен. И базовые навыки программирования хорошо помогают аналитику в его повседневной работе — проектировать решение.
Главное здесь не просто знание синтаксиса языка (это можно загуглить или спросить у нейросети), а умение строить алгоритмы, понимание, как требования ложатся на код.
Python — один из самых лёгких языков программирования для изучения с нуля. В настоящее время наиболее популярен в машинном обучении. Также на питоне можно делать скрипты, боты и полноценные веб-приложения.
🎓 Бесплатные курсы
1. "Поколение Python": курс для начинающих — самый популярный курс по Питону с нуля на Stepik
2. "Поколение Python": курс для продвинутых — курс для тех, кто прошёл предыдущий или у кого уже есть базовые знания по программированию
3. Программирование на Python — второй по популярности курс по Питону с нуля на Stepik
4. Python: основы и применение — продолжение предыдущего курса, а также для тех, кто имеет базовые навыки Питона
5. pythontutor.ru — интерактивный самоучитель, много задач, которые можно проверять автоматически и смотреть решения других людей
6. Python в примерах и задачах — курс от Дальневосточного федерального университета
7. Видеокурс от Школы бэкенд-разработки Яндекса — для продвинутых, поможет научиться промышленной разработке на Python
8. Тренажер по Python от Каталог-курсов.ру
9. Автоматизация тестирования с помощью Selenium и Python
1. Питон за час
2. Python-джедай (продолжение Питон за час)
3. Плейлист Python для начинающих
4. МФТИ, цикл лекций курса «Практики программирования»
5. Python программирование — плейлист для новичков
6. Язык программирования PYTHON для начинающих — 88 видео
7. Асинхронность в Python — плейлист для продвинутых
8. Разработка Telegram Ботов на Python с нуля
📚 Книги
(ссылки ведут на pdf)
1. Эрик Мэтиз. Изучаем Python: программирование игр, визуализация данных, веб-приложения
2. Пол Бэрри. Изучаем программирование на Python
3. Эл Свейгарт. Автоматизация рутинных задач с помощью Python
4. Марк Лутц. Python. Карманный справочник
5. Аллен Б. Дауни. Основы Python. Научитесь думать как программист
🌐 Полезные сайты
1. "Укус Питона" — "A Byte of Python" по-русски — подробный справочник по Питону с объяснениями
2. Запустить код пошагово с визуализацией
3. Визуализатор рекурсии — построить наглядное дерево вызовов
4. Простейший самоучитель по Python — можно использовать в качестве справочника
5. Репозиторий 30-Days-Of-Python (англ)
6. Freecodecamp — интерактивный учебник по Python (русского нет, зато есть украинский)
7. Онлайн-тренажёр «Прогноз погоды на Python» — интерактив от Яндекса по созданию программы, которая показывает температуру в любом городе мира
8. Адаптивный тренажер Python — несколько десятков разнообразных задач на Python разных уровней сложности
9. Тренажер “Codechick” — сборник практических заданий по Python, отсортированных по уровню сложности
Django
1. Курс видео по Django от EngineerSpock
2. Django 3 для python (уроки)
3. Создание сайта на Django
4. Django Web Development with Python (на русском)
💻 IDE
1. PyCharm: Windows / Linux / Mac
2. Spider
3. Непосредственно Python
📎 Ещё подборки и ссылки
1. Обучающие материалы по питону (roadmap) — огромная подборка материалов от корки до корки
2. 15+ небанальных ресурсов для начинающего/продолжающего Python-разработчика
3. 16 лучших сайтов уроков и заданий по Python в 2023 года
4. 144 книги по Python — можно скачать бесплатно
5. Бесплатные книги по Питону на все темы
#подборка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23👍18😱4❤2👏1💩1
Оркестрация и хореография в микросервисной архитектуре
В микросервисной архитектуре для организации взаимодействия микросервисов между собой используют два подхода: оркестрацию и хореографию.
Оркестрация – это подход, при котором есть центральный сервис (оркестратор), который координирует и управляет всеми остальными сервисами. Оркестратор знает всю логику бизнес-процесса и вызывает нужные сервисы в нужном порядке, передавая им необходимые данные и получая от них ответы. Оркестратор может использовать разные способы коммуникации с сервисами, например, REST, RPC, очереди сообщений и т.д. Пример "коробочного" решения для оркестрации: Camunda
✅ Плюсы оркестрации
💩 Можно быстрее понять и прозрачнее отследить логику бизнес-процесса, так как она сосредоточена в одном месте, а не размыта по всем сервисам сразу
💩 Легче вносить изменения в бизнес-процесс, так как достаточно изменить только оркестратор
💩 Легче обрабатывать ошибки и альтернативные сценарии, так как оркестратор контролирует выполнение всех шагов
⛔️ Минусы оркестрации
💩 Высокая связанность между сервисами, так как оркестратор зависит от интерфейсов и доступности всех сервисов, а сервисы зависят от того, что оркестратор передает им в качестве входных данных
💩 Оркестратор становится узким местом и единой точкой отказа
💩 Добавление новых сервисов или изменение порядка вызовов требует изменения оркестратора
Хореография – это подход, при котором нет центрального сервиса, который управляет всеми остальными. Вместо этого каждый сервис самостоятельно решает, что и когда делать, на основе событий, которые он получает от других сервисов. Сервисы публикуют события в общий канал (например, топик в Kafka) и подписываются на события, которые их интересуют. Таким образом, формируется цепочка реакций на события, которая реализует бизнес-процесс.
✅ Плюсы хореографии
💩 Низкая связанность между сервисами, так как сервисы не знают друг о друге и общаются только через события, а не через прямые вызовы
💩 Высокая масштабируемость и отказоустойчивость, так как нет единой точки отказа и каждый сервис может работать независимо от других
💩 Гибкость, так как можно легко добавлять новые сервисы или изменять поведение существующих, не затрагивая другие.
⛔️ Минусы хореографии
💩 Сложнее отследить логику бизнес-процесса, так как она размазана по разным сервисам и зависит от порядка и содержания событий
💩 При внесении изменений в какой-либо сервис нужно учитывать неявное влияние на все подписанные сервисы и избегать конфликтов или несогласованностей в данных. К тому же, могут потребоваться изменения сразу в нескольких сервисах.
💩 Сложно обрабатывать ошибки и исключения, так как нет централизованного механизма компенсации или отката
Что лучше?
🔹 Оркестрация подходит для сценариев, когда бизнес-процесс имеет четко определенную последовательность шагов, требует строгого контроля и согласованности, и не подвержен частым изменениям.
🔸 Хореография подходит для сценариев, когда бизнес-процесс имеет слабо связанные шаги, требует высокой производительности и масштабируемости, и подвержен динамическим изменениям.
📎 Статьи
1. Оркестрация и хореография микросервисов в EDA-архитектуре — немного теории + небольшая практика
2. Мониторинг и управление потоком задач в рамках взаимодействия микросервисов — здесь рассматривается оркестрация и хореография на практике
3. Сравнение подходов к реализации распределенных транзакций для микросервисов + более краткая версия статьи
3. Camunda: автоматизация бизнес-процессов и оркестрация микросервисов
4. Orchestration vs Choreography
5. Аналитика микросервисов. Практический опыт аналитика в enterprise
6. Паттерн Saga в микросервисной архитектуре
7. Сага о консистентности данных
8. Сага распределенных транзакций
⏯ Видео
1. Оркестрация и хореография. Как построить бизнес-процесс в зоопарке микросервисов — воркшоп Андрея Буракова на конференции Analyst Days-14 + ответы на вопросы по результатам воркшопа
2. Применение camunda для оркестрации микросервисов
3. Обзор паттернов интеграции микросервисов
#архитектура
В микросервисной архитектуре для организации взаимодействия микросервисов между собой используют два подхода: оркестрацию и хореографию.
Оркестрация – это подход, при котором есть центральный сервис (оркестратор), который координирует и управляет всеми остальными сервисами. Оркестратор знает всю логику бизнес-процесса и вызывает нужные сервисы в нужном порядке, передавая им необходимые данные и получая от них ответы. Оркестратор может использовать разные способы коммуникации с сервисами, например, REST, RPC, очереди сообщений и т.д. Пример "коробочного" решения для оркестрации: Camunda
✅ Плюсы оркестрации
⛔️ Минусы оркестрации
Хореография – это подход, при котором нет центрального сервиса, который управляет всеми остальными. Вместо этого каждый сервис самостоятельно решает, что и когда делать, на основе событий, которые он получает от других сервисов. Сервисы публикуют события в общий канал (например, топик в Kafka) и подписываются на события, которые их интересуют. Таким образом, формируется цепочка реакций на события, которая реализует бизнес-процесс.
✅ Плюсы хореографии
⛔️ Минусы хореографии
Что лучше?
🔹 Оркестрация подходит для сценариев, когда бизнес-процесс имеет четко определенную последовательность шагов, требует строгого контроля и согласованности, и не подвержен частым изменениям.
🔸 Хореография подходит для сценариев, когда бизнес-процесс имеет слабо связанные шаги, требует высокой производительности и масштабируемости, и подвержен динамическим изменениям.
📎 Статьи
1. Оркестрация и хореография микросервисов в EDA-архитектуре — немного теории + небольшая практика
2. Мониторинг и управление потоком задач в рамках взаимодействия микросервисов — здесь рассматривается оркестрация и хореография на практике
3. Сравнение подходов к реализации распределенных транзакций для микросервисов + более краткая версия статьи
3. Camunda: автоматизация бизнес-процессов и оркестрация микросервисов
4. Orchestration vs Choreography
5. Аналитика микросервисов. Практический опыт аналитика в enterprise
6. Паттерн Saga в микросервисной архитектуре
7. Сага о консистентности данных
8. Сага распределенных транзакций
1. Оркестрация и хореография. Как построить бизнес-процесс в зоопарке микросервисов — воркшоп Андрея Буракова на конференции Analyst Days-14 + ответы на вопросы по результатам воркшопа
2. Применение camunda для оркестрации микросервисов
3. Обзор паттернов интеграции микросервисов
#архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
👍39🔥13❤7⚡1
Паттерны API Gateway и BFF
В микросервисной архитектуре часто возникает вопрос, как организовать взаимодействие между клиентами (например, веб-приложениями или мобильными приложениями) и сервисами, которые предоставляют API. Для этого существуют два популярных паттерна: API Gateway и BFF (Backend For Frontend).
API Gateway – это компонент, который выступает в качестве единой точки входа в систему для всех клиентов. принимает запросы от клиентов, перенаправляет их к соответствующим микросервисам и возвращает ответы обратно к клиентам.
✅ Преимущества API Gateway
1️⃣ Упрощает использование API, так как клиентам не нужно знать о расположении и протоколах каждой системы и сервиса. При этом системы-источники данных избавляются от необходимости адаптироваться к каждому потребителю по отдельности
2️⃣ Обеспечивает единообразие и стандартизацию API для всех клиентов
3️⃣ Обеспечивает безопасность, так как API Gateway может осуществлять аутентификацию и авторизацию клиентов перед дальнейшими вызовами. Также API Gateway может вводить ограничения частоты запросов
4️⃣ Мониторинг и сбор показателей, что упрощает решение проблем и инцидентов
5️⃣ Сокращение количества сетевых вызовов, так как API Gateway может агрегировать и трансформировать данные из разных микросервисов в один ответ
6️⃣ Повышение производительности системы в целом и снижение нагрузки на системы-источники данных, так как API Gateway может кешировать данные, фильтровать запросы и применять политики доступа.
Однако зачастую кэширование на уровне API Gateway создаёт сложности согласованности данных (ведь у конечной системы тоже свой кэш), размазывает часть логики из разных систем на один компонент.
⛔️ Недостатки API Gateway
➖ Может стать узким местом и единой точкой отказа, если он не масштабируется и не защищается должным образом
➖ Добавляет некоторую задержку между запросом и ответом
➖ Может усложнить тестирование и отладку системы, так как он скрывает детали взаимодействия между сервисами
BFF – это вариация паттерна API Gateway, при которой для каждого типа клиента создается свой собственный API Gateway. Например, для сайта свой Web BFF, для приложения клиента App BFF, для ЛК сотрудника Emp BFF.
При использовании BFF каждый клиент получает оптимизированный для него интерфейс, который учитывает его особенности и потребности. BFF также может выполнять те же задачи, что и API Gateway, но с учетом специфики конкретного клиента.
✅ Преимущества BFF по сравнению с единым API Gateway для всех клиентов
1️⃣ Позволяет создавать более гибкие и настраиваемые API для каждого клиента, учитывая его различия в протоколах, форматах данных, функциональности и интерфейсе
2️⃣ Уменьшает объем передаваемых данных, так как BFF может отфильтровать и сократить ненужную информацию для клиента
3️⃣ Повышает независимость и ответственность команд, так как каждая команда может владеть и управлять своим BFF
⛔️ Недостатки BFF
В дополнение к ограничениям API Gateway, использование BFF может привести к дублированию кода и логики, если для разных клиентов требуются похожие функции
Промышленные решения для API Gateway и BFF
— Kong
— Istio
— Yandex Cloud
📎 Статьи
1. Что такое API-шлюзы и Gateway API
2. Pattern: API Gateway / Backends for Frontends — Крис Ричардсон
3. Pattern: Backends For Frontends — Сэм Ньюмэн
4. Опыт создания API Gateway
5. Использование паттерна BFF для создания общих типов в бэкенде и фронтенде
#архитектура
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше полезного в базе знаний по системному анализу
В микросервисной архитектуре часто возникает вопрос, как организовать взаимодействие между клиентами (например, веб-приложениями или мобильными приложениями) и сервисами, которые предоставляют API. Для этого существуют два популярных паттерна: API Gateway и BFF (Backend For Frontend).
API Gateway – это компонент, который выступает в качестве единой точки входа в систему для всех клиентов. принимает запросы от клиентов, перенаправляет их к соответствующим микросервисам и возвращает ответы обратно к клиентам.
✅ Преимущества API Gateway
1️⃣ Упрощает использование API, так как клиентам не нужно знать о расположении и протоколах каждой системы и сервиса. При этом системы-источники данных избавляются от необходимости адаптироваться к каждому потребителю по отдельности
2️⃣ Обеспечивает единообразие и стандартизацию API для всех клиентов
3️⃣ Обеспечивает безопасность, так как API Gateway может осуществлять аутентификацию и авторизацию клиентов перед дальнейшими вызовами. Также API Gateway может вводить ограничения частоты запросов
4️⃣ Мониторинг и сбор показателей, что упрощает решение проблем и инцидентов
5️⃣ Сокращение количества сетевых вызовов, так как API Gateway может агрегировать и трансформировать данные из разных микросервисов в один ответ
6️⃣ Повышение производительности системы в целом и снижение нагрузки на системы-источники данных, так как API Gateway может кешировать данные, фильтровать запросы и применять политики доступа.
Однако зачастую кэширование на уровне API Gateway создаёт сложности согласованности данных (ведь у конечной системы тоже свой кэш), размазывает часть логики из разных систем на один компонент.
⛔️ Недостатки API Gateway
➖ Может стать узким местом и единой точкой отказа, если он не масштабируется и не защищается должным образом
➖ Добавляет некоторую задержку между запросом и ответом
➖ Может усложнить тестирование и отладку системы, так как он скрывает детали взаимодействия между сервисами
BFF – это вариация паттерна API Gateway, при которой для каждого типа клиента создается свой собственный API Gateway. Например, для сайта свой Web BFF, для приложения клиента App BFF, для ЛК сотрудника Emp BFF.
При использовании BFF каждый клиент получает оптимизированный для него интерфейс, который учитывает его особенности и потребности. BFF также может выполнять те же задачи, что и API Gateway, но с учетом специфики конкретного клиента.
✅ Преимущества BFF по сравнению с единым API Gateway для всех клиентов
1️⃣ Позволяет создавать более гибкие и настраиваемые API для каждого клиента, учитывая его различия в протоколах, форматах данных, функциональности и интерфейсе
2️⃣ Уменьшает объем передаваемых данных, так как BFF может отфильтровать и сократить ненужную информацию для клиента
3️⃣ Повышает независимость и ответственность команд, так как каждая команда может владеть и управлять своим BFF
⛔️ Недостатки BFF
В дополнение к ограничениям API Gateway, использование BFF может привести к дублированию кода и логики, если для разных клиентов требуются похожие функции
Промышленные решения для API Gateway и BFF
— Kong
— Istio
— Yandex Cloud
📎 Статьи
1. Что такое API-шлюзы и Gateway API
2. Pattern: API Gateway / Backends for Frontends — Крис Ричардсон
3. Pattern: Backends For Frontends — Сэм Ньюмэн
4. Опыт создания API Gateway
5. Использование паттерна BFF для создания общих типов в бэкенде и фронтенде
#архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
👍27🔥16❤3👏2
Use Case. Как описывать и использовать
Use Case (синонимы: вариант использования, прецедент, сценарий) – это способ описания сценария взаимодействия пользователя с системой. Use Case помогает определить функциональные требования к системе, а также показать, как она взаимодействует с другими участниками.
UC рассматривает проектируемое ПО как «чёрный ящик», описывая взаимодействие с системой с точки зрения внешнего наблюдателя: что система должна сделать, чтобы актор достиг своей цели, а не как это должно быть реализовано в коде.
Важно понимать, что описание Use Case, как правило, полной постановкой для разработчика не является. UC помогает сформулировать общую концепцию системы, выявить основные сценарии использования, определить границы системы и ее взаимосвязь с внешней средой.
Use Case может состоять из следующих элементов
💩 Название. Кратко и однозначно отражает суть сценария
💩 Цель. Зачем нужен этот сценарий? Для чего? Без цели сценарий бесполезен
💩 Акторы. Участники, которые вовлечены в сценарий (человек или система)
💩 Предусловия. Условия, которые должны быть выполнены перед началом сценария
💩 Триггеры. События, которые запускают основной поток.
💩 Основной поток. Последовательность шагов, которые выполняются акторами для достижения цели сценария. Каждый шаг описывает действие актора и реакцию системы
💩 Альтернативные потоки. Варианты развития событий, которые отличаются от основного потока. Они могут быть вызваны ошибками, исключениями, выбором пользователя (if-else) или другими причинами
💩 Результат (Постусловия). Что получится на выходе сценария
💩 Бизнес-правила. Регламенты или ограничения, влияющие на Use Case
Как прорабатывать требования в формате Use Case
1️⃣ Определите акторов – людей и системы
2️⃣ Составьте список всех UC, которые задействуют акторов
3️⃣ Для каждого UC определить цель, предусловия, постусловия
4️⃣ Опишите основной поток каждого UC
5️⃣ Дополните описания UC альтернативными потоками
Use Case может быть описан в виде таблицы, текстом или на диаграмме UML.
Use Case 🆚 User Story
🔸 User Story — это краткое описание того, что хочет достичь пользователь, используя систему. Они обычно начинаются со слов «как пользователь, я хочу… «, и далее следует описание того, что пользователь хочет сделать. User Story сосредоточены на том, что пользователь хочет, а не на том, как это реализовать.
🔹 Use Case — это детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты. Use Case описывают, как система должна реагировать на действия пользователя.
📖 Книга: Алистер Коберн, «Современные методы описания функциональных требований»
📎 Статьи
1. Алгоритм описания функциональных требований к системе в формате Use Case — А. Вичугова и А. Гасраталиева / Systems Education
2. USE CASES. Что это такое и зачем они нужны?
3. Инструкция по работе со сценариями использования для молодого системного аналитика
4. Как мы создали шаблон функциональных требований к разработке ПО — от аналитиков МТС
5. Двадцать лет с юзкейсами: выжимаем практический опыт — статья от аналитика Qiwi
6. Усиление методики Use Case данное в книге Алистера Кобёрна — Евгений Скориков
7. Варианты на все случаи жизни: как написать полезный use case
8. Use Case и User Story: в чем разница
9. Ликбез по UML Use Case диаграмме
⏯ Видео
1. Использование Use case и User story для декомпозиции задач — Михаил Максимов
2. Фиксация требований с помощью Use Case / Демо-занятие курса «Системный аналитик»
3. Use Cases. Разбор вопросов и примеров диаграмм и описания от ЛАФ: часть 1 и часть 2
4. Идеальный USE CASE: как описать сценарий, чтобы его не вернули на доработку — MediaSoft
5. Как написать сценарий использования
#требования
Use Case (синонимы: вариант использования, прецедент, сценарий) – это способ описания сценария взаимодействия пользователя с системой. Use Case помогает определить функциональные требования к системе, а также показать, как она взаимодействует с другими участниками.
UC рассматривает проектируемое ПО как «чёрный ящик», описывая взаимодействие с системой с точки зрения внешнего наблюдателя: что система должна сделать, чтобы актор достиг своей цели, а не как это должно быть реализовано в коде.
Важно понимать, что описание Use Case, как правило, полной постановкой для разработчика не является. UC помогает сформулировать общую концепцию системы, выявить основные сценарии использования, определить границы системы и ее взаимосвязь с внешней средой.
Use Case может состоять из следующих элементов
Как прорабатывать требования в формате Use Case
1️⃣ Определите акторов – людей и системы
2️⃣ Составьте список всех UC, которые задействуют акторов
3️⃣ Для каждого UC определить цель, предусловия, постусловия
4️⃣ Опишите основной поток каждого UC
5️⃣ Дополните описания UC альтернативными потоками
Use Case может быть описан в виде таблицы, текстом или на диаграмме UML.
Use Case 🆚 User Story
🔸 User Story — это краткое описание того, что хочет достичь пользователь, используя систему. Они обычно начинаются со слов «как пользователь, я хочу… «, и далее следует описание того, что пользователь хочет сделать. User Story сосредоточены на том, что пользователь хочет, а не на том, как это реализовать.
🔹 Use Case — это детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты. Use Case описывают, как система должна реагировать на действия пользователя.
📖 Книга: Алистер Коберн, «Современные методы описания функциональных требований»
📎 Статьи
1. Алгоритм описания функциональных требований к системе в формате Use Case — А. Вичугова и А. Гасраталиева / Systems Education
2. USE CASES. Что это такое и зачем они нужны?
3. Инструкция по работе со сценариями использования для молодого системного аналитика
4. Как мы создали шаблон функциональных требований к разработке ПО — от аналитиков МТС
5. Двадцать лет с юзкейсами: выжимаем практический опыт — статья от аналитика Qiwi
6. Усиление методики Use Case данное в книге Алистера Кобёрна — Евгений Скориков
7. Варианты на все случаи жизни: как написать полезный use case
8. Use Case и User Story: в чем разница
9. Ликбез по UML Use Case диаграмме
1. Использование Use case и User story для декомпозиции задач — Михаил Максимов
2. Фиксация требований с помощью Use Case / Демо-занятие курса «Системный аналитик»
3. Use Cases. Разбор вопросов и примеров диаграмм и описания от ЛАФ: часть 1 и часть 2
4. Идеальный USE CASE: как описать сценарий, чтобы его не вернули на доработку — MediaSoft
5. Как написать сценарий использования
#требования
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥47👍15❤11
Forwarded from Библиотека Системного Аналитика
Сюй_А_System_Design_Подготовка_к_сложному_интервью_2022.pdf
3.9 MB
System Design. Подготовка к сложному интервью
✍️ Автор: Алекс Сюй
🗓 Год издания: 2022
🔤 Язык: русский
📚 Объём: 304 стр.
Описание:
Интервью по System Design (проектированию ИТ-систем) очень популярны у работодателей, на них легко проверить ваши навыки общения и оценить умение решать реальные задачи.
Пройти такое собеседование непросто, поскольку в проектировании ИТ-систем не существует единственно правильных решений. Речь идет о самых разнообразных реальных системах, обладающих множеством особенностей. Вам могут предложить выбрать общую архитектуру, а потом пройтись по всем компонентам или, наоборот, сосредоточиться на каком-то одном аспекте. Но в любом случае вы должны продемонстрировать понимание и знание системных требований, ограничений и узких мест.
Правильная стратегия и знания являются ключевыми факторами успешного прохождения интервью!
Что внутри?
💩 Инсайдерская информация: что на самом деле нужно интервьюерам
💩 4-х шаговый подход к решению любой задачи system design
💩 16 вопросов из реальных интервью с подробными решениями.
💩 188 диаграмм, наглядно объясняющих, как работают реальные системы.
#проектирование
✍️ Автор: Алекс Сюй
🗓 Год издания: 2022
🔤 Язык: русский
📚 Объём: 304 стр.
Описание:
Интервью по System Design (проектированию ИТ-систем) очень популярны у работодателей, на них легко проверить ваши навыки общения и оценить умение решать реальные задачи.
Пройти такое собеседование непросто, поскольку в проектировании ИТ-систем не существует единственно правильных решений. Речь идет о самых разнообразных реальных системах, обладающих множеством особенностей. Вам могут предложить выбрать общую архитектуру, а потом пройтись по всем компонентам или, наоборот, сосредоточиться на каком-то одном аспекте. Но в любом случае вы должны продемонстрировать понимание и знание системных требований, ограничений и узких мест.
Правильная стратегия и знания являются ключевыми факторами успешного прохождения интервью!
Что внутри?
#проектирование
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥45👍20👏6❤1
JSON и JSON Schema
JSON (JavaScript Object Notation) — это структурированный текстовый формат обмена данными. Легко читается людьми. Имеет открытый стандарт.
Где используется
JSON независим от языков программирования и используется повсеместно, например:
💩 при обмене данными через API. Например, мы можем как один из вариантов передавать body HTTP-запроса в формате JSON (но не обязательно только JSON!)
💩 при создании параметров конфигурации для систем и сервисов
💩 в NoSQL базах данных, например, в MongoDB
Синтаксис
Json-объект — это неупорядоченное множество пар вида {"ключ": "значение"}.
💩 Ключ – это название параметра, пишется в двойных кавычках
💩 Значение для ключа указывается после двоеточия
💩 Между парами ключ-значение ставится запятая. После последней пары запятая не ставится
💩 Писать ключи можно в любом порядке
Типы данных
💩 Строка –
💩 Число – целое или с запятой –
💩 boolean – true или false –
💩 null – пустое значение –
💩 Массив –
💩 Объект –
Классический JSON (по стандарту RFC 8259) не поддерживает комментарии. Однако существует расширение стандартного JSON – JSON5, в котором можно вставлять комментарии.
А где же тип “дата”? JSON не даёт строгих указаний, в каком формате передавать дату и время. Можно использовать unix-time или передавать дату в строке по ISO 8601, например,
JSON Schema
JSON Schema – это способ описания структуры и ограничений JSON-документов. Схема создана для описания JSON-данных, но и сама она при этом является JSON-объектом. С помощью ключевых слов в схеме создаются правила валидации структуры объекта и типов его полей.
В отличие от XML-схемы, которая имеет стандарт и строго диктует определение документа в рамках XML, JSON-схема более гибкая и простая.
Применение JSON Schema
1️⃣ Описание формата данных в API-контрактах, которое читается машиной и понятно человеку
2️⃣ Валидация данных в JSON-документах. Здесь имеется в виду не просто проверка на корректность формата, а проверка специфических требований и ограничений
3️⃣ Автоматическая генерация примеров запросов и ответов API: JSON Schema позволяет генерировать динамические данные, соответствующие схеме. Эти примеры ответов можно использовать для создания заглушек
4️⃣ Создание автоматической документации к API
5️⃣ Автоматическая генерация кода. На основе схемы можно создавать SDK для API на любой платформе
📄 Спецификации
1. RFC 8259 — про JSON
2. ISO 8601 — про формат дат
3. JSON Schema
4. JSON5
📎 Материалы по JSON
0. Пример JSON
1. Что такое JSON и как с ним работать
2. Хорошо написанная статья в англоязычной Википедии
3. Типичные ошибки в JSON
4. JSON онлайн редактор
5. JSON конвертер в YAML
6. XML конвертер в JSON
7. YAML конвертер в JSON, XML, CSV
📎 Материалы по JSON Schema
1. Объяснение JSON-схемы с примерами от ВК
2. JSON Schema. Быть или не быть?
3. Понимание JSON схемы
4. Пример JSON-схемы
5. Пример онлайн-валидатора JSON-схемы
6. Конвертер JSON-схемы на разные языки
⏯ Видео
1. JSON за 5 минут
2. Формат JSON. От основ к практике
3. Полный курс по JSON для начинающих
4. Валидация JSON в Postman
#проектирование #api
JSON (JavaScript Object Notation) — это структурированный текстовый формат обмена данными. Легко читается людьми. Имеет открытый стандарт.
Где используется
JSON независим от языков программирования и используется повсеместно, например:
Синтаксис
Json-объект — это неупорядоченное множество пар вида {"ключ": "значение"}.
Типы данных
"name": "Вася""years": 24"resident": true"children": null"experience": [ "Повар", 2, "Аналитик", 1 ]"experience": { "Повар": 2, "Аналитик": 1 }Классический JSON (по стандарту RFC 8259) не поддерживает комментарии. Однако существует расширение стандартного JSON – JSON5, в котором можно вставлять комментарии.
А где же тип “дата”? JSON не даёт строгих указаний, в каком формате передавать дату и время. Можно использовать unix-time или передавать дату в строке по ISO 8601, например,
"2012-04-21T18:25:43-05:00".JSON Schema
JSON Schema – это способ описания структуры и ограничений JSON-документов. Схема создана для описания JSON-данных, но и сама она при этом является JSON-объектом. С помощью ключевых слов в схеме создаются правила валидации структуры объекта и типов его полей.
В отличие от XML-схемы, которая имеет стандарт и строго диктует определение документа в рамках XML, JSON-схема более гибкая и простая.
Применение JSON Schema
1️⃣ Описание формата данных в API-контрактах, которое читается машиной и понятно человеку
2️⃣ Валидация данных в JSON-документах. Здесь имеется в виду не просто проверка на корректность формата, а проверка специфических требований и ограничений
3️⃣ Автоматическая генерация примеров запросов и ответов API: JSON Schema позволяет генерировать динамические данные, соответствующие схеме. Эти примеры ответов можно использовать для создания заглушек
4️⃣ Создание автоматической документации к API
5️⃣ Автоматическая генерация кода. На основе схемы можно создавать SDK для API на любой платформе
1. RFC 8259 — про JSON
2. ISO 8601 — про формат дат
3. JSON Schema
4. JSON5
📎 Материалы по JSON
0. Пример JSON
1. Что такое JSON и как с ним работать
2. Хорошо написанная статья в англоязычной Википедии
3. Типичные ошибки в JSON
4. JSON онлайн редактор
5. JSON конвертер в YAML
6. XML конвертер в JSON
7. YAML конвертер в JSON, XML, CSV
📎 Материалы по JSON Schema
1. Объяснение JSON-схемы с примерами от ВК
2. JSON Schema. Быть или не быть?
3. Понимание JSON схемы
4. Пример JSON-схемы
5. Пример онлайн-валидатора JSON-схемы
6. Конвертер JSON-схемы на разные языки
1. JSON за 5 минут
2. Формат JSON. От основ к практике
3. Полный курс по JSON для начинающих
4. Валидация JSON в Postman
#проектирование #api
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥45👍19❤8
CAP-теорема
CAP-теорема – это утверждение о том, что в любой распределенной системе можно обеспечить выполнение только 2-х из 3-х следующих свойств:
1️⃣ Consistency (согласованность) – все узлы распределенной системы содержат актуальные и одинаковые данные в любой момент времени. Это свойство гарантирует, что любой запрос к системе вернет правильный и последний результат, независимо от того, к какому узлу он обращается.
2️⃣ Availability (доступность) – каждый запрос к системе возвращает результат. Без гарантий, что результат содержит последние данные. Даже если какие-то узлы выпали, система всё равно должна вернуть ответ.
3️⃣ Partition tolerance (устойчивость к разделению) – система продолжает работать даже при потере коммуникации между узлами. Например, если между двумя узлами отвалилась связь, то они продолжают работать независимо друг от друга.
Варианты сочетания свойств
💫 💫 (Consistency + Availability) – все узлы системы имеют одинаковые и актуальные данные, и все запросы получают ответ. Такие системы возможны при поддержке ACID-требований к транзакциям (Атомарность, Согласованность, Изоляция, Долговечность) и абсолютной надежности сети. На практике таких решений почти не существует. Классическим примером CA-системы называют распределённую службу каталогов LDAP, а также реляционные базы данных (PostgreSQL, MySQL, MS SQL Server).
💫 💫 (Consistency + Partition tolerance) – все узлы системы имеют одинаковые и актуальные данные, и система продолжает работать, даже если между узлами потеряно соединение. Однако, эти системы могут не отвечать на некоторые запросы. Устойчивость к разделению требует дублирования изменений во всех узлах системы.
Как это работает: система CP отрабатывает транзакцию только в том случае, если изменения удалось распространить по всем узлам. Система продолжает обрабатывать запросы даже при отказе одного из узлов. Но пока система не убедится в своей целостности и согласованности, запросы могут не обрабатываться или обрабатываться с задержкой.
Примеры хранилищ данных: Apache HBase, MongoDB, Redis.
💫 💫 (Availability + Partition tolerance) – все запросы получают ответ, и система продолжает работать, даже если между узлами потеряно соединение. Эти системы подходят для обработки данных, когда требуется высокая доступность, но можно претерпеть небольшие расхождения в данных. AP-система может быть представлена кластером из нескольких узлов, каждый из которых может принимать данные, но не обязуется в тот же момент распространять их на другие сервера. Такая система отлично справляется с отказами нескольких узлов, но возможна выдача пользователям старых данных. К AP-системам относят CoucheDB, Cassandra, Amazon DynamoDB.
Так как де-факто в распределённых системах сеть может пропадать, соответственно, приходится поддерживать устойчивость к разделению (P). Остаётся пойти на компромисс между согласованностью (C) и доступностью (A).
Применимость CAP-теоремы
Следует учитывать недостатки теоремы CAP. Большинство из них сводится к тому, что теорема CAP заставляет делать жесткий выбор между двумя из трех свойств, хотя на практике можно достичь различных компромиссов и гибридных решений. CAP не даёт метрик для измерения доступности или согласованности данных.
Основная ценность CAP-теоремы в том, что она поднимает вопрос о неизбежности компромиссов при проектировании распределённых систем. Необходимо осознанно выбирать, какие из принципов будут иметь приоритет, исходя из конкретных требований системы.
📎 Статьи по теме
1. CAP-теорема: принципы согласованности, доступности и устойчивости
2. CAP-теорема простым, доступным языком
3. Несколько фактов о CAP-«теореме»
4. CAP двенадцать лет спустя: как изменились «правила»
5. Всё, что вы не знали о CAP теореме
6. Мифы о CAP теореме
#проектирование
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше полезного в базе знаний по системному анализу
CAP-теорема – это утверждение о том, что в любой распределенной системе можно обеспечить выполнение только 2-х из 3-х следующих свойств:
1️⃣ Consistency (согласованность) – все узлы распределенной системы содержат актуальные и одинаковые данные в любой момент времени. Это свойство гарантирует, что любой запрос к системе вернет правильный и последний результат, независимо от того, к какому узлу он обращается.
2️⃣ Availability (доступность) – каждый запрос к системе возвращает результат. Без гарантий, что результат содержит последние данные. Даже если какие-то узлы выпали, система всё равно должна вернуть ответ.
3️⃣ Partition tolerance (устойчивость к разделению) – система продолжает работать даже при потере коммуникации между узлами. Например, если между двумя узлами отвалилась связь, то они продолжают работать независимо друг от друга.
Варианты сочетания свойств
Как это работает: система CP отрабатывает транзакцию только в том случае, если изменения удалось распространить по всем узлам. Система продолжает обрабатывать запросы даже при отказе одного из узлов. Но пока система не убедится в своей целостности и согласованности, запросы могут не обрабатываться или обрабатываться с задержкой.
Примеры хранилищ данных: Apache HBase, MongoDB, Redis.
Так как де-факто в распределённых системах сеть может пропадать, соответственно, приходится поддерживать устойчивость к разделению (P). Остаётся пойти на компромисс между согласованностью (C) и доступностью (A).
Применимость CAP-теоремы
Следует учитывать недостатки теоремы CAP. Большинство из них сводится к тому, что теорема CAP заставляет делать жесткий выбор между двумя из трех свойств, хотя на практике можно достичь различных компромиссов и гибридных решений. CAP не даёт метрик для измерения доступности или согласованности данных.
Основная ценность CAP-теоремы в том, что она поднимает вопрос о неизбежности компромиссов при проектировании распределённых систем. Необходимо осознанно выбирать, какие из принципов будут иметь приоритет, исходя из конкретных требований системы.
📎 Статьи по теме
1. CAP-теорема: принципы согласованности, доступности и устойчивости
2. CAP-теорема простым, доступным языком
3. Несколько фактов о CAP-«теореме»
4. CAP двенадцать лет спустя: как изменились «правила»
5. Всё, что вы не знали о CAP теореме
6. Мифы о CAP теореме
#проектирование
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26👍9❤5⚡1
Паттерны CQRS и Event Sourcing в микросервисной архитектуре
CQRS (Command and Query Responsibility Segregation) — это паттерн, который предлагает разделить операции чтения и записи на отдельные типы операций: Query (запросы) и Command (команды).
Query — операция, которая возвращает данные из хранилища, но не изменяют его. В HTTP Query соответствует метод GET.
Command — операция, которая изменяет состояние хранилища, но не возвращают данные. В HTTP Commands соответствуют методы POST/PUT/PATCH/DELETE.
Event Sourcing — паттерн хранения данных в виде последовательности событий. Идея в том, чтобы записывать в БД каждое событие, которое меняет состояние какой-либо сущности.
База данных, куда записываются события, называется event source. Данные в ней изменять нельзя, и, как правило, они записаны в денормализованном виде – специально, чтобы операция чтения выполнялась как можно быстрее.
Как CQRS и Event Sourcing работают вместе?
Организуем два хранилища данных:
💩 Первое – первоисточник данных. Используется в командах
💩 Второе – оптимизированное для чтения хранилище. Данные сюда сохраняются после выполнения команд.
Процесс при выполнении команд:
1. Микросервис получает команду, проверяет её валидность
2. Если команда валидна, микросервис выполняет команду и генерирует событие
3. Микросервис сохраняет событие в хранилище-первоисточник
4. Микросервис публикует событие в очередь сообщений, где его могут подписаться другие микросервисы
5. Каждый микросервис, который подписан на это событие, обновляет свое хранилище для чтения, применяя событие к своей проекции данных.
6. В хранилище для чтения получаем новый слепок состояния первоисточника данных
При обработке запросов
1. Микросервис получает запрос, который должен вернуть данные из системы.
2. Микросервис обращается к своему хранилищу для чтения (event source), и возвращает данные, не обращаясь к хранилищу для записи.
✅ Преимущества CQRS и Event Sourcing
💩 Независимое масштабирование. CQRS позволяет раздельно масштабировать нагрузки чтения и записи, снижая риски конфликтов
💩 Оптимизированные схемы данных. Для query можно применить схему, оптимизированную для запросов, а для command — другую схему, оптимизированную для изменений
💩 Безопасность. Разделение операций позволяет настроить более гибкую систему доступа.
💩 Восстановление состояния. С помощью Event Sourcing можно восстановить состояние системы на любой момент времени, откатить ошибочные операции или исправить поврежденные данные.
⛔️ Недостатки
💩 Сложность. Несмотря на простоту идеи, реализация CQRS + Event Sourcing может привести к усложнению проекта приложения, особенно если реализовывать его в связке с другими паттернами, такими как Domain-Driven Design, Saga, Eventual Consistency и т.д.
💩 Несогласованность данных. Из-за асинхронной природы обмена сообщениями, данные в хранилищах для чтения и записи могут быть не согласованы на некоторое время.
💩 Сложнее тестирование и отладка
📎 Статьи
1. Паттерны CQRS и Event Sourcing
2. Погружение в CQRS
3. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS: часть 1 и часть 2
4. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS
5. Сможет ли Event Sourcing перерасти базы данных?
#архитектура
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше полезного в базе знаний по системному анализу
CQRS (Command and Query Responsibility Segregation) — это паттерн, который предлагает разделить операции чтения и записи на отдельные типы операций: Query (запросы) и Command (команды).
Query — операция, которая возвращает данные из хранилища, но не изменяют его. В HTTP Query соответствует метод GET.
Command — операция, которая изменяет состояние хранилища, но не возвращают данные. В HTTP Commands соответствуют методы POST/PUT/PATCH/DELETE.
Event Sourcing — паттерн хранения данных в виде последовательности событий. Идея в том, чтобы записывать в БД каждое событие, которое меняет состояние какой-либо сущности.
База данных, куда записываются события, называется event source. Данные в ней изменять нельзя, и, как правило, они записаны в денормализованном виде – специально, чтобы операция чтения выполнялась как можно быстрее.
Как CQRS и Event Sourcing работают вместе?
Организуем два хранилища данных:
Процесс при выполнении команд:
1. Микросервис получает команду, проверяет её валидность
2. Если команда валидна, микросервис выполняет команду и генерирует событие
3. Микросервис сохраняет событие в хранилище-первоисточник
4. Микросервис публикует событие в очередь сообщений, где его могут подписаться другие микросервисы
5. Каждый микросервис, который подписан на это событие, обновляет свое хранилище для чтения, применяя событие к своей проекции данных.
6. В хранилище для чтения получаем новый слепок состояния первоисточника данных
При обработке запросов
1. Микросервис получает запрос, который должен вернуть данные из системы.
2. Микросервис обращается к своему хранилищу для чтения (event source), и возвращает данные, не обращаясь к хранилищу для записи.
✅ Преимущества CQRS и Event Sourcing
⛔️ Недостатки
📎 Статьи
1. Паттерны CQRS и Event Sourcing
2. Погружение в CQRS
3. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS: часть 1 и часть 2
4. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS
5. Сможет ли Event Sourcing перерасти базы данных?
#архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥6❤2👏2
Forwarded from Библиотека Системного Аналитика
Тарасенко_Ф_П_Прикладной_системный_анализ.pdf
6.4 MB
«Прикладной системный анализ»
Прикладной системный анализ
✍️ Автор: Ф.П. Тарасенко
🗓 Год издания: 2017
🔤 Язык: русский
📚 Объём: 321 стр.
Описание:
Книга считается классикой отечественной школы теории систем. Автор описывает базовые понятия системологии, необходимые для обоснования и изложения технологии системного анализа, а также рекомендует последовательность операций и методы преодоления трудностей при решении проблем различной природы. Книга содержит множество примеров, контрольных вопросов и заданий, а также ссылки на дополнительную литературу. Книга будет полезна всем тем, кто хотят научиться системному мышлению и применять его в своей деятельности.
#развитие
Прикладной системный анализ
✍️ Автор: Ф.П. Тарасенко
🗓 Год издания: 2017
🔤 Язык: русский
📚 Объём: 321 стр.
Описание:
Книга считается классикой отечественной школы теории систем. Автор описывает базовые понятия системологии, необходимые для обоснования и изложения технологии системного анализа, а также рекомендует последовательность операций и методы преодоления трудностей при решении проблем различной природы. Книга содержит множество примеров, контрольных вопросов и заданий, а также ссылки на дополнительную литературу. Книга будет полезна всем тем, кто хотят научиться системному мышлению и применять его в своей деятельности.
#развитие
👍31🔥13❤8
🆚 Сравнение JSON, XML и YAML
JSON, XML и YAML — это языки сериализации данных, то есть способы представления структурированных данных в виде текста. Сериализация данных позволяет обмениваться данными по API и не только, а также часто используется в качестве описания параметров конфигураций.
➖ JSON часто используется в веб-разработке и API благодаря простоте и эффективности парсинга.
➖ XML часто используется в легаси-системах, когда критически важна безопасность передаваемых данных. Может быть менее эффективным в обработке из-за сложной структуры.
➖ YAML менее популярен, но предпочтителен для конфигурационных файлов и удобочитаемых данных благодаря простоте и читаемости. На нём, кстати, составляется разметка Swagger для документации REST API.
Подготовили для вас более подробную сравнительную таблицу основных характеристик каждого формата. Надеемся, вам будет полезно.
В комментариях таблица без сжатия
#сравнение
JSON, XML и YAML — это языки сериализации данных, то есть способы представления структурированных данных в виде текста. Сериализация данных позволяет обмениваться данными по API и не только, а также часто используется в качестве описания параметров конфигураций.
Подготовили для вас более подробную сравнительную таблицу основных характеристик каждого формата. Надеемся, вам будет полезно.
В комментариях таблица без сжатия
#сравнение
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥45👍12❤9🥱2
🐳 Docker: Краткое описание и подборка материалов
Docker — это платформа для разработки, доставки и запуска приложений в контейнерах. Помогает развернуть множество контейнеров на одной хост-машине независимо от ее операционной системы.
Основные понятия
💩 Контейнер — изолированная среда, в которой запускаются приложения вместе со всеми зависимостями, включая библиотеки и компоненты, необходимые для работы приложения.
💩 Image (образ) — шаблон для создания контейнера, описывающий, что именно должно быть в контейнере. Образы можно создавать самостоятельно или загружать из репозиториев, таких как Docker Hub.
💩 Dockerfile — текстовый файл с инструкцией для создания образа (что должно находиться в образе, какие команды, зависимости и процессы он будет содержать)
💩 Registry (реестр/репозиторий) —удалённое (открытое / закрытое) хранилище образов. Docker Hub – публичное хранилище образов.
💩 Host — ОС, на которой работает Docker.
💩 Platform — программа, которая упаковывает и запускает приложения в контейнере. Собирает код и зависимости
💩 Volumes — хранилище данных для приложения.
💩 Docker Compose — инструмент для определения и запуска многоконтейнерных приложений с помощью YAML-файла. Docker Compose позволяет настроить параметры, такие как имя сервиса, образ, порты, тома, сети и зависимости между сервисами.
💩 Docker Swarm — режим работы Docker, в котором несколько хостов объединяются в кластер для управления и масштабирования контейнеров. Docker Swarm обеспечивает высокую доступность, балансировку нагрузки и обнаружение сервисов.
Архитектура Docker
Docker построен на клиент-серверной архитектуре. Docker-Client общается с Docker-Daemon, который создает, запускает, распределяет контейнеры. Клиент и сервер могут работать как на одной машине, так и удаленно. Интерфейс общения: Socket или REST API.
✏️ Примеры использования
➖ Работа с веб-приложением. К примеру, веб-приложение на PHP и нужно его запустить на своем компьютере. Вместо того, чтобы устанавливать PHP, веб-сервер и др. зависимости напрямую, можно использовать Docker для создания контейнера, в который упаковывается всё необходимое для работы веб-приложения.
Далее этот контейнер запускается на вашем компьютере и веб-приложение работает в изолированной среде, не требуя установки всех компонентов на операционной системе.
➖ Контейнеризация БД. Например, компания использует БД MongoDB для хранения данных. Чтобы облегчить управление и развертывание, администратор использует Docker для создания контейнера с MongoDB. Этот контейнер содержит необходимую версию MongoDB и все конфигурационные файлы. Это позволяет легко масштабировать, резервировать и обновлять базу данных с минимальными усилиями, а также обеспечивает изоляцию от других приложений и сервисов.
➖ Работа с микросервисами. Например, есть веб-приложение, состоящее из нескольких микросервисов: сервис авторизации, обработки заказов и управления пользователями.
Каждый микросервис может быть упакован в свой собственный Docker-контейнер:
один с Node.js для авторизации, другой с Python для обработки заказов и так далее.
Это облегчает масштабирование и управление каждым сервисом независимо.
✅ Преимущества
▫️Изоляция и безопасность: Docker помогает создавать изолированные среды для разработки и тестирования ПО без влияния на основную систему. Например, перенести приложение со всеми зависимостями на другую систему с помощью пары команд в терминале.
▫️Ускорение разработки: Docker позволяет быстро создавать и уничтожать контейнеры. Разработчики могут работать над приложением независимо от ОС
▫️Масштабируемость и отказоустойчивость: позволяет запускать одно приложение в нескольких контейнерах для повышения производительности. Для масштабирования используются платформы оркестрации: OpenShift, Kubernetes, Docker Swarm, Nomad, и тд
⛔️ Недостатки
◾️Повышенная потребность в вычислительных ресурсах
◾️Необходимость оркестрации для крупных приложений
◾️Сложности на Windows и macOS (так как изначально разработан для Linux)
Подборка материалов в следующем посте 👇
#инструменты
Docker — это платформа для разработки, доставки и запуска приложений в контейнерах. Помогает развернуть множество контейнеров на одной хост-машине независимо от ее операционной системы.
Основные понятия
Архитектура Docker
Docker построен на клиент-серверной архитектуре. Docker-Client общается с Docker-Daemon, который создает, запускает, распределяет контейнеры. Клиент и сервер могут работать как на одной машине, так и удаленно. Интерфейс общения: Socket или REST API.
✏️ Примеры использования
Далее этот контейнер запускается на вашем компьютере и веб-приложение работает в изолированной среде, не требуя установки всех компонентов на операционной системе.
Каждый микросервис может быть упакован в свой собственный Docker-контейнер:
один с Node.js для авторизации, другой с Python для обработки заказов и так далее.
Это облегчает масштабирование и управление каждым сервисом независимо.
✅ Преимущества
▫️Изоляция и безопасность: Docker помогает создавать изолированные среды для разработки и тестирования ПО без влияния на основную систему. Например, перенести приложение со всеми зависимостями на другую систему с помощью пары команд в терминале.
▫️Ускорение разработки: Docker позволяет быстро создавать и уничтожать контейнеры. Разработчики могут работать над приложением независимо от ОС
▫️Масштабируемость и отказоустойчивость: позволяет запускать одно приложение в нескольких контейнерах для повышения производительности. Для масштабирования используются платформы оркестрации: OpenShift, Kubernetes, Docker Swarm, Nomad, и тд
⛔️ Недостатки
◾️Повышенная потребность в вычислительных ресурсах
◾️Необходимость оркестрации для крупных приложений
◾️Сложности на Windows и macOS (так как изначально разработан для Linux)
Подборка материалов в следующем посте 👇
#инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19❤10👍5