1. Безопасность типов: Аннотации типов помогают выявить несоответствие типов на ранней стадии, что уменьшает количество ошибок и гарантирует, что ваш код будет вести себя так, как ожидается.

2. Самодокументированный код: Подсказки типов повышают удобочитаемость кода и выступают в роли встроенной документации, уточняя ожидаемые типы входных и выходных данных функций.

3. Повышение качества кода: Использование подсказок типов способствует улучшению дизайна и архитектуры, способствуя продуманному планированию и реализации структур данных и интерфейсов.

4. Улучшенная поддержка инструментов: Такие инструменты, как mypy, используют аннотации типов для статической проверки типов, выявляя потенциальные ошибки до начала выполнения, тем самым упрощая процесс разработки и тестирования.

5. Поддержка современных библиотек: FastAPI, Pydantic и другие библиотеки используют аннотации типов для автоматизации валидации данных, генерации документации и уменьшения дублирования кода.

6. Преимущества типизированных классов данных перед простыми структурами данных: Типизированные классы данных улучшают читаемость, работу со структурированными данными и безопасность типов по сравнению с массивами и кортежами. Они используют атрибуты вместо строковых ключей, что минимизирует ошибки из-за опечаток и улучшает автодополнение кода. Датаклассы также обеспечивают четкое определение структур данных, поддерживают значения по умолчанию, упрощают сопровождение и отладку кода.

Почему нам нужно разделить приложение на слои

Разделение приложения на слои повышает ремонтопригодность, масштабируемость и гибкость. Ключевые причины для этой стратегии включают:

Разделение забот

• Каждый слой фокусируется на определенном аспекте, что упрощает разработку, отладку и сопровождение.

Возможность повторного использования

• Слои можно повторно использовать в различных частях приложения или в других проектах. Исключается дублирование кода.

Масштабируемость

• Позволяет различным слоям масштабироваться независимо друг от друга в зависимости от потребностей.

Удобство обслуживания

• Упрощает обслуживание за счет локализации общих функций в отдельных слоях.

Улучшенная совместная работа

• Команды могут работать над разными слоями независимо друг от друга.

Гибкость и адаптируемость

• Изменения в технологиях или дизайне могут быть реализованы в определенных слоях. В адаптации нуждаются только затронутые слои, остальные остаются незатронутыми.

Тестируемость

• Каждый слой можно тестировать независимо, что упрощает модульное тестирование и отладку.

Использование многоуровневой архитектуры дает значительные преимущества в скорости разработки, оперативном управлении и долгосрочном обслуживании, делая системы более надежными, управляемыми и адаптируемыми к изменениям.

Глобальные константы против инжектируемых параметров

При разработке программного обеспечения выбор между использованием глобальных констант и применением инъекции зависимостей (DI) может существенно повлиять на гибкость, сопровождаемость и масштабируемость приложений. В этом анализе рассматриваются недостатки глобальных констант и противопоставляются им преимущества, обеспечиваемые инъекцией зависимостей.

Глобальные константы

1. Фиксированная конфигурация: Глобальные константы статичны и не могут динамически адаптироваться к различным средам или требованиям без изменения кодовой базы. Такая жесткость ограничивает их использование в различных сценариях работы.

2. Ограниченный объем тестирования: Тестирование становится сложным при использовании глобальных констант, поскольку их нелегко переопределить. Разработчикам может потребоваться изменять глобальное состояние или использовать сложные обходные пути, чтобы приспособиться к различным сценариям тестирования, что повышает риск ошибок.

3. Уменьшение модульности: Опора на глобальные константы снижает модульность, поскольку компоненты становятся зависимыми от конкретных значений, установленных глобально. Такая зависимость снижает возможность повторного использования компонентов в различных проектах или контекстах.

4. Высокая связанность: Глобальные константы интегрируют специфическое поведение и конфигурации непосредственно в кодовую базу, что затрудняет адаптацию или развитие приложения без значительных изменений.

5. Скрытые зависимости: Подобно глобальным переменным, глобальные константы скрывают зависимости внутри приложения. Становится неясно, какие части системы зависят от этих констант, что усложняет понимание и сопровождение кода.

6. Трудности сопровождения и рефакторинга: Со временем использование глобальных констант может привести к проблемам с обслуживанием. Рефакторинг такой кодовой базы рискован, поскольку изменения констант могут случайно затронуть разные части приложения.

7. Дублирование состояния на уровне модуля: В Python код на уровне модуля может выполняться несколько раз, если импорт происходит по разным путям (например, абсолютный и относительный). Это может привести к дублированию глобальных экземпляров и трудноотслеживаемым ошибкам в обслуживании.

Инжектируемые параметры

1. Динамическая гибкость и настраиваемость: Инъекция зависимостей позволяет динамически настраивать компоненты, делая приложения адаптируемыми к изменяющимся условиям без необходимости изменения кода.

2. Улучшенная тестируемость: DI улучшает тестируемость, позволяя внедрять моки или альтернативные конфигурации во время тестирования, эффективно изолируя компоненты от внешних зависимостей и обеспечивая более надежные результаты тестирования.

3. Увеличение модульности и возможности повторного использования: Компоненты становятся более модульными и пригодными для повторного использования, поскольку они спроектированы так, чтобы работать с любыми инжектируемыми параметрами, соответствующими ожидаемым интерфейсам. Такое разделение задач повышает переносимость компонентов в различные части приложения или даже в разные проекты.

4. Низкая связанность: Инжектируемые параметры способствуют низкой связанности, отделяя логику системы от ее конфигурации. Такой подход облегчает обновление и внесение изменений в приложение.

5. Явное декларирование зависимостей: В DI компоненты явно объявляют о своих зависимостях, обычно через параметры конструктора или сеттеры. Такая ясность облегчает понимание, поддержку и расширение системы.

6. Масштабируемость и управление сложностью: По мере роста приложений DI помогает управлять сложностью, локализуя проблемы и отделяя конфигурацию от использования, что способствует эффективному масштабированию и обслуживанию больших систем.

Процедурное программирование против ООП

Использование объектно-ориентированного программирования (ООП) и инъекции зависимостей (DI) может значительно повысить качество и сопровождаемость кода по сравнению с процедурным подходом с глобальными переменными и функциями. Вот простое сравнение, демонстрирующее эти преимущества:

Процедурный подход: Глобальные переменные и функции

• Дублирование кода: database_config должен передаваться или обращаться глобально в нескольких функциях.

• Трудности тестирования: Имитация подключения к базе данных или конфигурации предполагает манипулирование глобальным состоянием, что чревато ошибками.

• Высокая связанность: Функции напрямую зависят от глобального состояния и конкретных реализаций.

ООП + DI-подход

• Уменьшено дублирование кода: Конфигурация базы данных инкапсулируется в объекте подключения.

• Возможности DI: Легко заменить MySQLConnection на другой класс подключения к базе данных, например PostgresConnection, не изменяя код UserService.

• Энкапсуляция и абстракция: Детали реализации того, как извлекаются пользователи или как подключается база данных, скрыты от глаз.

• Удобство моков и тестирования: UserService можно легко протестировать, внедрив заглушку DatabaseConnection.

• Управление временем жизни объекта: Жизненным циклом соединений с базой данных можно управлять более детально (например, с помощью менеджеров контекста).

• Использование принципов ООП: Демонстрирует наследование (абстрактный базовый класс), полиморфизм (реализация абстрактных методов) и протоколы (интерфейсы, определенные DatabaseConnection).

Благодаря структурированию приложения с использованием ООП и DI, код становится более модульным, его легче тестировать, и он становится гибким к изменениям, таким как замена зависимостей или изменение конфигурации.

Создание программы

Все примеры и более подробную информацию с комментариями вы можете найти в репозитории

Начало нового проекта

Небольшой чек-лист:

1. Управление проектами и зависимостями с помощью Poetry

poetry new python-app-architecture-demo

Эта команда создаст минимальную структуру директории: отдельные папки для приложения и тестов, файл метаинформации проекта pyproject.toml, лок файлы зависимостей и конфигурации гита.

2. Контроль версий с помощью Git

Инициализируйте гит:

git init

Добавьте файл .gitignore для исключения ненужных файлов из вашего репозитория. Используйте стандартный .gitignore, предоставленный GitHub, и добавьте остальные исключения, такие как .DS_Store для macOS и папки редакторов (.idea, .vscode, .zed, etc):

wget -O .gitignore https://raw.githubusercontent.com/github/gitignore/main/Pyth...

echo .DS_Store >> .gitignore

3. Управление зависимостями

Установите зависимости вашего проекта с помощью poetry:

poetry add fastapi pytest aiogram

Вы можете установить все зависимости позже, используя:

poetry install

Обратитесь к официальной документации каждой библиотеки, если вам нужны более конкретные инструкции.

4. Файлы конфигурации

Создайте файл config.py для централизации настроек приложения - это распространенный и эффективный подход.

Установите переменные окружения для секретов и настроек:

touch .env example.env

.env содержит конфиденциальные данные и должен быть git-ignored, в то время как example.env содержит placeholder или значения по умолчанию и хранится в репозитории.

5. Точка входа приложения

Определите точку входа вашего приложения в main.py:

python_app_architecture/main.py:

Сделайте свой проект пригодным для использования в качестве библиотеки и разрешите программный доступ, импортировав функцию run в __init__.py:

python_app_architecture/init.py

Включите прямое выполнение проекта с помощью Poetry, добавив ярлык в __main__.py. Это позволит вам использовать команду poetry run python python_app_architecture вместо более длинной poetry run python python_app_architecture/main.py.

python_app_architecture/main.py:

Определение каталогов и слоев

Дисклеймер:
Конечно, все приложения разные, и их архитектура будет отличаться в зависимости от целей и задач. Я не говорю, что это единственно правильный вариант, но мне кажется, что он достаточно средний и подходит для значительной части проектов. Постарайтесь сосредоточиться на основных подходах и идеях, а не на конкретных примерах.

Теперь давайте настроим директории для различных слоев приложения.

Как правило, имеет смысл версионировать API (например, создавая подкаталоги типа api/v1), но мы пока будем действовать проще и опустим этот шаг.

• app

  • entities - структуры данных всего приложения. Чисто носители данных без логики.

  • general - чемодан с инструментами. Папка для общих утилит, помощников и оберток библиотек.

  • mappers - специалисты по преобразованию данных, таких как модели баз данных в сущности, или между различными форматами данных. Хорошей практикой является инкапсуляция мапперов в границах их использования, вместо того чтобы держать их глобальными. Например, маппер models-entities может быть частью модуля репозитория. Другой пример: маппер schemas-entities должен оставаться внутри сервиса апи и быть его приватным инструментом.

  • providers - основа бизнес-логики. Провайдеры реализуют основную логику приложения, но остаются независимыми от деталей интерфейса, обеспечивая абстрактность и изолированность своих операций.

  • repositores - библиотекари. Хранители доступа к данным, абстрагирующие сложности взаимодействия с бд.

    • models - определения локальных структур базы данных, не путать с сущностями entities.

  • services - каждый сервис действует как (почти) автономное подприложение, организуя свою специфическую область бизнес-логики и делегируя основные задачи провайдерам. Такая конфигурация обеспечивает централизованную и единообразную логику всего приложения

    • api_service - управляет внешними коммуникациями по http/s, структурированными вокруг фреймворка FastAPI.

      • dependencies - основные инструменты и помощники, необходимые для различных частей вашего API, интегрированные с помощью системы DI FastAPI

      • endpoints - конечные точки http интерфейса

      • schemas - определения структур данных для запросов и ответов апи

    • telegram_service - работает аналогично сервису апи, предоставляя тот же функционал в другом интерфейсе, но без дублирования кода бизнес-логики за счет вызова тех же провайдеров, чир использует апи сервис.

• tests - директория предназначена исключительно для тестирования и содержит весь тестовый код, сохраняя четкое разделение с логикой приложения.

Связь между слоями будет выглядеть примерно так:

Обратите внимание, что entities - не активные компоненты, а лишь структуры данных, которые передаются между слоями:

Помните, что слои не связаны напрямую, а зависят только от абстракций. Реализации передаются с помощью инъекции зависимостей:

Такая гибкая структура позволяет легко добавить функциональность, например, изменить базу данных, создать сервис или подключить новый интерфейс без лишних изменений и дублирования кода, так как логика каждого модуля находится на своем слое:

В то же время вся логика отдельного сервиса инкапсулируется внутри него:

Изучение кода

Эндпоинт

Начнем с конечной точки:

1. Импортируем вспомогательную функцию инъекции зависимостей (мы рассмотрим ее через минуту)

2. Импортируем UserProvider protocol для аннотации типа

3. Конечная точка требует, чтобы тело запроса содержало схему UserCreate в формате json

4. Параметр provider в функции register представляет собой экземпляр реализации UserProvider, инжектируемый FastAPI с помощью механизма Depends.

5. В метод create_user функции UserProvider передаются распарсенные данные пользователя. Это демонстрирует четкое разделение проблем, когда уровень API делегирует бизнес-логику уровню провайдера, придерживаясь принципа, что интерфейсные уровни не должны содержать бизнес-логику.

UserProvider

Теперь давайте посмотрим на бизнес-логику:

1. Определение интерфейса: UserProvider - это протокол, определяющий метод create_user, который должен реализовать любой класс, придерживающийся этого протокола. Он служит формальным контрактом для функциональности создания пользователя.

2. Протокол наблюдателя: UserProviderOutput служит в качестве наблюдателя (или делегата), который получает уведомление о создании пользователя. Этот протокол обеспечивает свободное соединение и улучшает событийно-ориентированную архитектуру приложения.

3. Реализация протокола: UserProviderImpl реализует логику создания пользователя, но ему не нужно явно декларировать свою приверженность UserProvider из-за динамической природы Python и использования утиной типизации.

4. Основные зависимости: Конструктор принимает UserRepository и MailProvider - оба определены как протоколы - в качестве параметров. Полагаясь исключительно на эти протоколы, UserProviderImpl остается отделенным от конкретных реализаций, иллюстрируя принципы Dependency Injection, где провайдер не зависит от базовых деталей, взаимодействуя только через определенные контракты.

5. Опциональный делегат вывода: Конструктор принимает необязательный экземпляр UserProviderOutput, который, если он предоставлен, будет уведомлен по завершении создания пользователя.

6. Функция обратного вызова: В качестве альтернативы делегату вывода можно передать вызываемую функцию on_user_created для обработки дополнительных действий после создания пользователя, обеспечивая гибкость реакции на события.

7. Центральная бизнес-логика: Метод create_user инкапсулирует основную бизнес-логику для добавления пользователя, демонстрируя отделение от обработки API.

8. Взаимодействие с репозиторием: Использует UserRepository для абстрагирования операций с базой данных (например, добавление пользователя), гарантируя, что провайдер не будет напрямую манипулировать базой данных.

9. Расширенная бизнес-логика: Вовлекает отправку электронной почты через MailProvider, иллюстрируя, что обязанности провайдера могут выходить за рамки простых CRUD-операций.

10. Уведомление о событиях: Если предоставлен делегат вывода, он уведомляет его о событии создания пользователя, используя паттерн наблюдателя для повышения интерактивности и модульной реакции на события.

11. Исполнение обратного вызова: Опционально выполняет функцию обратного вызова, обеспечивая простой метод расширения функциональности без сложных иерархий классов или зависимостей.

Зависимости FastAPI

Хорошо, но как инстанцировать провайдер и внедрить его? Давайте посмотрим на код инъекции, реализованный с помощью DI-движка FastAPI:

1. Получение сессии базы данных через систему инъекций зависимостей FastAPI, гарантируя, что каждый запрос имеет чистую сессию.

2. Получение из состояния приложения экземпляра Coordinator, который отвечает за управление более широкими задачами на уровне приложения и выступает в качестве менеджера событий.

3. Примечание: функция возвращает протокол, но не точную реализацию.

4. Конструирование экземпляра UserProviderImpl путем инжекции всех необходимых зависимостей. Это демонстрирует практическое применение инъекции зависимостей для сборки сложных объектов.

5. Инициализация UserRepository с сессией, полученной из DI-системы FastAPI. Этот репозиторий обрабатывает все операции по сохранению данных, абстрагируя взаимодействие с базой данных от провайдера.

6. Настройка MailProvider с помощью конфигурационного токена.

7. Инжектирование Coordinator в качестве выходного протокола. При этом предполагается, что Coordinator реализует протокол UserProviderOutput, что позволяет ему получать уведомления о создании пользователя.

8. Назначает метод из Coordinator в качестве обратного вызова, который будет выполняться при создании пользователя. Это позволяет запускать дополнительные операции или уведомления в качестве побочного эффекта процесса создания пользователя.

Такой структурированный подход гарантирует, что UserProvider оснащен всеми необходимыми инструментами для эффективного выполнения своих задач, придерживаясь при этом принципов свободной связи и высокой связности.

Координатор

Класс Coordinator выступает в роли главного оркестратора в вашем приложении, управляя различными сервисами, взаимодействиями, событиями, устанавливая начальное состояние и внедряя зависимости. Вот подробное описание его ролей и функциональных возможностей на основе предоставленного кода:

1. Некоторые состояния могут быть общими для разных провайдеров, служб, слоев и всего приложения.

2. Сборка реализаций и внедрение зависимостей

3. Здесь следует помнить о круговых ссылках, тупиках и утечках памяти, подробности см. в полном коде.

4. Передайте экземпляр координатора в состояние приложения FastAPI, чтобы вы могли обращаться к нему в конечных точках через DI-систему FastAPI.

5. Запустить все сервисы в отдельных потоках

6. Уже запускается в отдельном потоке внутри сервиса

7. Некоторая кросс-сервисная логика, просто для примера

8. Пример управления сервисами из координатора

Этот оркестратор централизует управление и связь между различными компонентами, повышая управляемость и масштабируемость приложения. Он эффективно координирует действия между сервисами, обеспечивая адекватную реакцию приложения на изменения состояния и взаимодействие с пользователем. Этот шаблон проектирования очень важен для поддержания чистого разделения задач и обеспечения более надежного и гибкого поведения приложения.

Контейнер DI

Однако в крупномасштабных приложениях ручное использование DI может привести к появлению значительного количества шаблонного кода. Именно тогда на помощь приходит DI Container. DI Containers, или Dependency Injection Containers, - это мощные инструменты, используемые при разработке программного обеспечения для управления зависимостями в приложении. Они служат в качестве центрального места, где регистрируются и управляются объекты и их зависимости. Когда объекту требуется зависимость, DI-контейнер автоматически обрабатывает инстанцирование и предоставление этих зависимостей, гарантируя, что объекты получат все необходимые компоненты для эффективного функционирования. Такой подход способствует свободному соединению, улучшает тестируемость и общую сопровождаемость кодовой базы за счет абстрагирования сложной логики управления зависимостями от бизнес-логики приложения. DI-контейнеры упрощают процесс разработки, автоматизируя и централизуя конфигурацию зависимостей компонентов.

Для python существует множество библиотек, предоставляющих различные реализации DI Container, я просмотрел почти все из них и записал лучшие IMO

• python-dependency-injector - автоматизирован, основан на классах, имеет различные варианты жизненного цикла, такие как Singleton или Factory

• lagom - интерфейс словаря с автоматическим разрешением

• dishka - хороший контроль области видимости через менеджер контекста

• that-depends - поддержка контекстных менеджеров (объекты должны быть закрыты в конце), встроенная интеграция fastapi

• punq - более классический подход с методами register и resolve.

• rodi - классический, простой, автоматический

main.py

В завершение обновим файл main.py:

Заключение

Чтобы получить полное представление об обсуждаемых архитектурных и реализационных стратегиях, полезно просмотреть все файлы в репозитории. Несмотря на ограниченный объем кода, каждый файл снабжен содержательными комментариями и дополнительными деталями, которые позволяют глубже понять структуру и функциональность приложения. Изучение этих аспектов улучшит ваше знакомство с системой, гарантируя, что вы будете хорошо подготовлены к эффективной адаптации или расширению приложения.

Этот подход универсален для различных приложений на Python. Он эффективен для бэкенд-серверов без состояния, например, построенных с помощью FastAPI, но его преимущества особенно ярко проявляются в приложениях без фреймворка и приложениях, управляющих состоянием. Сюда относятся настольные приложения (как с графическим интерфейсом, так и с командной строкой), а также системы, управляющие физическими устройствами, например IoT-устройствами, робототехникой, дронами и другими технологиями, ориентированными на аппаратное обеспечение.

Кроме того, я настоятельно рекомендую прочитать книгу Чистый код Роберта Мартина для дальнейшего обогащения. Краткое содержание и основные выводы вы можете найти здесь. Этот ресурс предоставит вам основополагающие принципы и практики, которые крайне важны для поддержания высоких стандартов в разработке программного обеспечения.

О других интересных проектах периодически пишу в телеграм.

1. Безопасность: Бэкэнд помогает защитить конфиденциальные данные и токены аутентификации пользователей от атак типа MITM (Man-in-the-Middle). Он выступает в качестве защищенного шлюза между пользовательским устройством и базой данных или внешними службами, обеспечивая шифрование и аутентификацию всех данных.

2. Контроль над использованием сервисов: Управляя API и взаимодействием с пользователями через бэкэнд, вы можете отслеживать и контролировать использование приложения. Это включает в себя дросселирование для управления нагрузкой, предотвращение злоупотреблений и обеспечение эффективного использования ресурсов.

3. Интеграция с базой данных: Бэкэнд обеспечивает бесшовную интеграцию с базами данных, позволяя динамически хранить, извлекать и обновлять данные в режиме реального времени. Это важно для приложений, которые требуют учетных записей пользователей, хранят их предпочтения или нуждаются в быстром и безопасном получении больших объемов данных.

4. Модели подписки и Freemium: Реализация услуг по подписке или модели freemium требует наличия бэкенда для выставления счетов, отслеживания использования и управления уровнями пользователей. Бэкэнд может безопасно обрабатывать платежи и подписки, обеспечивая бесперебойную работу пользователей и соблюдая требования по защите данных.

5. Масштабируемость и обслуживание: Бэкэнд позволяет более эффективно масштабировать приложение. Логику на стороне сервера можно обновлять без необходимости передавать обновления клиенту, что упрощает обслуживание и ускоряет внедрение новых функций.

По сути, бэкенд — это не только функциональность, но и создание безопасной, масштабируемой и устойчивой среды для процветания вашего приложения.

Объяснение технического стека

• SwiftUI: Лучший вариант для нативных приложений для iOS после выхода UIKit. Он декларативен и упорядочен, а XCode является незаменимым редактором благодаря эпл. Для android код можно легко перевести на Kotlin с помощью Jetpack Compose.

• FastAPI: Выбран для бэкенда за его скорость, минимальное количество шаблонов и декларативность, редактируется с помощью превосходного Zed.dev.

• ChatGPT API: Используется в качестве большой языковой модели (LLM); выбор может меняться в зависимости от необходимости кастомизации.

• Ngrok: Реализует туннелирование с помощью простой команды CLI для выхода локального сервера в интернет.

Создание приложения для iOS

Теория: Архитектурные паттерны

1. MVVMP (Model View ViewModel Presenter):

• Model: Представляет собой структуры данных, используемые в приложении, такие как Question, Answer, Questionary и FilledQuestionary. Эти модели просты и содержат только данные, следуя принципу KISS.

• View: Отвечают только за представление пользовательского интерфейса и делегируют все данные и логику презентерам. Они не содержат никакой бизнес-логики и спроектированы так, чтобы быть простыми и сосредоточенными на рендере UI.

• ViewModel: В SwiftUI ViewModel представлена объектом ObservableObject, который служит моделью наблюдения за изменяемыми данными. Здесь нет методов и логики.

• Presenter: Presenter управляет всей логикой, связанной с модулем (экраном или представлением), но не бизнес-логикой. Он взаимодействует с доменным слоем для выполнения операций бизнес-логики, таких как взаимодействие с API или управление сохранением данных.

• Domain Layer: Этот слой содержит бизнес-логику приложения и взаимодействует с внешними ресурсами, такими как базы данных, API или другие сервисы. Он состоит из нескольких компонентов, таких как сервисы, провайдеры, менеджеры, репозитории, мапперы, фабрики и т. д.

• На самом деле, MP в MVVMP является инициалами Марка Паркера, а полная форма — «Model View ViewModel by Mark Parker».

1. Принципы СОЛИД:

   • Принцип единой ответственности: У каждого класса должна быть только одна причина для изменений.

   • Принцип открытость-закрытость: Компоненты должны быть открыты для расширения, но закрыты для модификации.

   • Принцип замещения Лискова: Объекты суперкласса должны быть заменяемы объектами подклассов.

   • Принцип разделения интерфейсов: Ни один клиент не должен быть вынужден зависеть от интерфейсов, которые он не использует.

   • Принцип инверсии зависимостей: Зависимость от абстракций, а не от конкретики, чему способствует DI.

2. Инъекция зависимостей (DI): Реализация с использованием DI-контейнера для соблюдения принципа инверсии зависимостей.

Разработка бэкенда

Код бэкенда довольно прост. Эндпоинты (main.py):

"onboarding" предоставляет список вопросов анамнеза, которые необходимо заполнить при первом запуске приложения. Ответы будут сохранены на устройстве и использованы для персонализированной диагностики в будущем. "doctor" — основной эндпоинт: он генерирует вопросы на основе предыдущих ответов и карты пользователя, либо возвращает результат диагностики.

Модели:

Промпты:

Модуль промптов использует GPT-3.5 от OpenAI для генерации ответов на основе пользовательского ввода, анамнеза и заполненных анкет. Он возвращает пользователю соответствующие вопросы и советы по диагностике здоровья. Как видите, ничего сложного здесь нет. Код элементарен, а промпты - просто набор четких инструкций для LLM.

Настройте окружение и запустите сервер с помощью fastapi dev main.py.

Подробности:

• fastapi.tiangolo.com/tutorial/first-steps

• pypi.org/project/openai/

Открытие доступа к локальному хосту через Интернет

1. Зарегистрируйтесь на сайте ngrok.com и получите токен доступа.

2. Установите ngrok с сайта ngrok.com/download.

3. Выполните команду ngrok config add-authtoken <TOKEN>.

4. Запустите с помощью команды ngrok http http://localhost:8080 (при необходимости измените порт).

Подробные инструкции по настройке можно найти в документации ngrok.

Кодим приложение

Я не буду показывать здесь весь исходный код, для этого есть GitHub. Найти его можно по адресу: HouseMDAI iOS App. Вместо этого я остановлюсь только на важных (IMO) моментах.

Начнем с краткого описания задачи: нам нужно приложение с текстовым полем на главном экране, возможностью задавать набор динамических вопросов и показывать ответ. Также нам нужен одноразовый онбординг. Итак, приступим к коду.

Первым делом нам нужны модели, и они довольно просты (принцип KISS).

Теперь давайте сделаем онбординг. Продолжаем следовать KISS и SRP (Single Responsibility Principle), никакой бизнес-логики в представлениях, только UI. В данном случае - только список вопросов с прокруткой. Все данные и логика делегированы презентеру. Единственное, что здесь интересно, это небольшой вспомогательный метод bindingForQuestion, который, вероятно, должен быть в презентере, но сейчас это не имеет значения.

Вы будете удивлены, но в презентере также нет никакой бизнес-логики!

Все по-прежнему simple, stupid и имеет только одну ответственность. Presenter должен содержать только логику своего представления. Бизнес-логика уровня приложения находится вне его юрисдикции, поэтому презентер просто делегирует ее наверх по стэку вызова.

Также можно заметить, что и View, и Presenter не инстанцируют ни одну из зависимостей, а получают их в качестве параметров при инициализации. Это соответствует принципу инверсии зависимостей, согласно которому модули высокого уровня не должны зависеть от модулей низкого уровня, но оба должны зависеть от абстракций. Это обеспечивает гибкость и упрощает тестирование, а также позволяет легко заменять зависимости или внедрять макеты для целей тестирования.

При использовании паттерна Dependency Injection зависимости предоставляются извне класса, а не инстанцируются внутри него. Это способствует развязке и позволяет упростить поддержку и тестирование кода.

Хотя в данном примере протоколы не используются явно, стоит отметить, что протоколы могут играть важную роль в коде, особенно для абстрагирования и облегчения тестирования. Определив протоколы для представлений, презентаторов и зависимостей, становится проще заменять реализации или предоставлять моки во время тестирования.

Если вы рассматриваете возможность использования протоколов в представлениях SwiftUI, необходимо помнить об одном важном моменте. Поскольку View в SwiftUI - это структура, она требует явного указания типов своих свойств. Это означает, что вам придется сделать её дженериком и пробрасывать тип через весь стек вызовов, что приведет к появлению большого количества шаблонного кода.

Однако существует альтернативный подход, предлагаемый MarkParker5/AnyObservableObject.
Эта библиотека работает аналогично родным оберткам свойств SwiftUI, но убирает проверку типа во время компиляции в пользу проверки во время рантайма. Хотя такой подход может внести некоторые риски, их легко снизить, написав элементарные xcode тесты, которые просто инициализируют представления так же, как вы делаете это во время рантайма.

Используя эту альтернативу, вы можете упростить свой код и оптимизировать процесс работы с протоколами в SwiftUI.

Итак, если презентер не содержит бизнес-логику, то где же она? Это задача для доменного слоя, который обычно содержит сервисы, провайдеры и менеджеры. У них всех очень схожее применение, и разница между ними до сих пор является предметом дискуссий. Давайте создадим OnboardingProvider, который будет содержать всю бизнес-логику процесса онбординга.

Опять же, он выполняет только одну задачу: управление бизнес-логикой процесса onboarding. Такая инкапсуляция позволяет другим классам взаимодействовать с ним без необходимости беспокоиться о деталях его внутренней реализации, что способствует созданию более чистой и удобной кодовой базы.

Теперь давайте соберем все вместе в корне приложения.

Это приложение SwiftUI устанавливает свое начальное состояние с помощью оберток полей StateObject. Оно инициализирует OnboardingProvider, OnboardingPresenter и HomePresenter в своем методе init. Провайдер OnboardingProvider отвечает за управление данными, связанными с онбордингом, а OnboardingPresenter управляет логикой представления онбординга. HomePresenter управляет главным домашним представлением.

В теле сцены приложения проверяется, нужна ли регистрация на сайте. Если да, то она представляет OnboardingView с OnboardingPresenter. В противном случае она представляет TabView, содержащий HomeView с HomePresenter и, если доступно, ProfileView.

Теперь настало время для домашнего экрана. Логика проста:

1. Получаем сообщение от пользователя

2. Используя сообщение, запрашиваем список вопросов из бэкенда

3. Показываем вопросы по одному, используя встроенную push-навигацию.

4. Добавляем ответы к запросу и повторяем 2-4, пока бэкенд-доктор не вернет окончательный результат

5. Показываем финальный результат

Похоже, я пропустил 4-й пункт... или нет? Поскольку представление не может содержать никакой логики, эту часть выполняет его презентер.

Он управляет вводом сообщения пользователем и обновляет путь навигации на основе ответов от бэкенда.

При отправке сообщения метод onSend() отправляет его на бэкенд с помощью DoctorProvider и ожидает ответа. В зависимости от типа ответа он обновляет навигационный путь, отображая либо набор вопросов, либо окончательный ответ.

Аналогично, когда заполняется вопросник, метод onQuestionaryFilled() отправляет заполненный вопросник на бэкенд и соответствующим образом обновляет путь навигации.

Здесь есть небольшое дублирование кода между методами onSend() и onQuestionaryFilled(), которое можно было бы отрефакторизовать в один метод для обработки обоих случаев. Однако оставим это как упражнение для дальнейшей доработки.

Модуль Questionary (View+Presenter) почти является копией Onboarding и просто делегирует логику до HomePresenter, поэтому я не вижу необходимости показывать код. Опять же, для этого есть github.

Последнее, что я хочу показать, это две реализации DoctorProvider, единственной обязанностью которых является вызов API и возврат DoctorResponse.

Первая использует наш бэкенд:

Вторая вызывает openai api напрямую (подход backendless) и является практически копией модуля подсказок из бэкенда:

Обе реализации легко взаимозаменяются благодаря инъекции зависимостей:

Другой пример

Посмотреть пример этой архитектуры в реальном приложении можно в моем проекте TwiTreads на github.com/MarkParker5/TwiTreads

Что делать дальше

• Интегрируйте аутентификацию и базу данных пользователей в бэкенд. Можете использовать официальный шаблон FastAPI из FastAPI Project Generation.

• Реализуйте логику аутентификации в приложении.

• Сосредоточьтесь на улучшении дизайна приложения, чтобы повысить удобство работы с ним. Давайте создавать красивые приложения!

Заключение

Приведенные проекты и ссылки на код служат реальными примерами, чтобы дать толчок вашей собственной разработке. Помните, что красота технологии заключается в итерациях. Начните с простого, создайте прототип и постоянно совершенствуйте его. Каждый шаг вперед приближает вас к овладению искусством разработки программного обеспечения и, возможно, к следующему большому прорыву в технологиях. Счастливого кодинга!

О других интересных проектах периодически пишу в телеграм.

После тщательного анализа мы определили лучшие обучающие программы по архитектуре микросервисов, которые могут вывести выпускников на профессиональный уровень.

ТОП-10 лучших курсов по микросервисной архитектуре в 2024 году

1. Микросервисная архитектура от Otus.ru — лучший тренинг по освоению инструментов для разработки микросервисов.

2. Микросервисы: проектирование и интеграция на GO от Slurm — идеальные уроки по разделению монолита на микросервисы.

3. DevOps-инженер от Нетология — эффективное обучение развертыванию Kubernetes и автоматизированному управлению конфигурацией.

4. Python-разработчик от Eduson Academy — возможность освоить универсальный язык Python.

5. DevOps-инженер PRO от Skillbox.ru — уроки по эффективному сочетанию процессов разработки и эксплуатации.

6. ClickHouse для инженеров и архитекторов БД от Otus.ru — идеальные лекции по использованию ClickHouse в своей работе.

7. Microservices - паттерны от PurpleSchool — самое быстрое изучение универсальных шаблонов, полезных разработчикам на разных языках.

8. Enterprise Architect от Otus.ru — эффективное обучение анализу компании и улучшению ее архитектуры.

9. Полный путь от монолита на Rails к микросервисной архитектуре от Thinknetica — лучшие лекции по успешному внедрению архитектуры в производство.

10. Микросервисная архитектура от IBS Training Center — наиболее подробное изучение вопросов развертывания и методов обеспечения необходимых качеств архитектуры.

Этот набор тренингов предназначен для бизнес-аналитиков, системных администраторов, а также менеджеров проектов, продуктов и портфолио. Перечисленные обучающие программы дают необходимые навыки для принятия обоснованных решений, способствующих развитию вашей компании или направления. Погружение в главные аспекты микросервисов и их интеграцию позволит вам эффективно управлять проектами, анализировать процессы и успешно внедрять современные архитектурные подходы.

Онлайн-курсы по микросервисной архитектуре

1. Микросервисная архитектура | Otus.ru

Программа предназначена для архитекторов, системных аналитиков, разработчиков и администраторов, стремящихся овладеть передовыми методами разработки микросервисных систем. Она включает в себя решение нетривиальных задач проектирования, направленных на создание масштабируемых и отказоустойчивых приложений. Вы узнаете, как использовать классические шаблоны проектирования, такие как сегментирование и репликация, а также освоите работу с Kubernetes.

• Стоимость: от 14 637 рублей в месяц

• Длительность: 5 месяцев

• Формат обучения: онлайн-лекции, практические задания, итоговый проект

• Сертификат: да

Преимущества:

• возможность получать обратную связь;

• создание фреймворка интернет-магазина как практический проект;

• учебные модули с акцентом на реальный опыт;

• знания экспертов.

Недостатки:

• ограниченное время для практических занятий;

• иногда преподаватели слишком спешат.

Программа обучения:

• Базовые паттерны

• Инфраструктура микросервисов

• Инструменты наблюдаемости

• Коммуникационные паттерны

• Распределенные системы и хранилища

• Проектная работа

Ознакомиться с полной программой >>>

2. Микросервисы: проектирование и интеграция на GO | Slurm

Тренинг от Петра Щербакова, опытного архитектора решений, дает представление о разделении монолита на микросервисы. В течение месяца обучения вы измените свой образ мышления, освоите шаблоны и структуры микросервисной архитектуры. Эксперты из ведущих компаний Марсель Ибраев и Павел Селиванов поделятся с вами практическим опытом и глубоким пониманием эффективного проектирования и интеграции микросервисов.

• Стоимость: от 45 000 рублей

• Длительность: 36 часов

• Формат обучения: вебинары, домашние и практические задания, тестирование

• Сертификат: да

Преимущества:

• спикер с 8-летним опытом коммерческой разработки;

• обучение на реальных кейсах;

• обратная связь от спикера;

• доступ к материалам сохраняется в течение 2 лет;

• большое количество практических заданий для глубокого понимания темы.

Недостатки:

• некоторые уроки требуют больше практических примеров;

• необходимо поработать над структурой учебной программы.

Программа обучения:

• Анализ монолита, основные проблемы монолитов

• Проектирование и стратегия разделения часть

• Документирование

• Управление изменениями и поддержка

• Встреча со спикером

• Рассмотрение механизмов интеграции

• Реализация механизмов интеграции

Ознакомиться с полной программой >>>

3. DevOps-инженер | Нетология

Тренинг предназначен для тех, кто стремится стать высокооплачиваемым специалистом по DevOps. Под руководством опытных преподавателей Булата Замилова и Андрея Копылова вы освоите все ключевые инструменты для решения инфраструктурных задач и автоматизации процессов. Слушатели узнают, как администрировать кластер Kubernetes, работать с Ansible, настраивать удаленные серверы и использовать Terraform для настроек серверной инфраструктуры. Приобретенные навыки позволят вам организовывать проекты с использованием облачных провайдеров, настраивать процессы CI/CD и успешно применять подход DevOps в реальных проектах.

• Стоимость: от 2916 рублей в месяц

• Длительность: 7,5 месяцев

• Формат обучения: вебинары, видеолекции, практические задания

• Сертификат: диплом о переподготовке

Преимущества:

• занятия проводятся три раза в неделю с возможностью записи;

• прохождение дипломного семинара в облачном сервисе Yandex Cloud;

• построение современного процесса DevOps;

• создание портфолио;

• поддержка командой экспертов, координаторов и менторов.

Недостатки:

• возможны переносы занятий;

• при подаче заявки на тренинг могут возникнуть небольшие трудности.

Программа обучения:

• Инфраструктура как код, непрерывная разработка

• Kubernetes

Ознакомиться с полной программой >>>

4. Python-разработчик | Eduson Academy

Уроки разработаны для тех, кто хочет стать востребованным специалистом в области создания веб-приложений, видеоигр, искусственного интеллекта. Изучив универсальный язык Python, вы сможете выбрать сферу деятельности, от тестирования до создания инновационных решений. Студенты углубляются в теорию и практику алгоритмов, математики и структур данных. Тренинг обеспечивает не только техническую базу, но и готовит выпускников к решению реальных задач.

• Стоимость: 5434 руб./мес.

• Длительность: 6 месяцев

• Формат обучения: онлайн-лекции, практические задания, дипломный проект

• Сертификат: диплом о переподготовке

Преимущества:

• теория и практика по алгоритмам, математике и структуре данных;

• диплом о повышении квалификации и оценке 7 проектов;

• тренинг разработан профессионалами из Германии, Японии, Израиля;

• проверка кода каждого проекта для получения подробных консультаций и оптимизации;

• 365 дней поддержки наставника;

• гарантированное трудоустройство на 6 месяцев.

Недостатки:

• некоторые докладчики сложно объясняют материал;

• возможны задержки с проверкой домашних заданий.

Программа обучения:

• Основы программирования

• Python и фреймворки

• ООП

• Базы данных

• Git и GitHub

• Автотестирование

Ознакомиться с полной программой >>>

5. DevOps-инженер PRO | Skillbox.ru

Программа создана для тех, кто стремится стать высококвалифицированным специалистом по DevOps. Вы начнете с освоения системного администрирования, а затем глубже погрузитесь в DevOps. Студенты осваивают Docker, Terraform, Ansible и Kubernetes, приобретая навыки для автоматизации процессов и управления инфраструктурой.

• Стоимость: 6309 рублей в месяц

• Длительность: 12 месяцев

• Формат обучения: видео и текстовые материалы, практические задания, тестирование

• Сертификат: да

Преимущества:

• ориентация на требования работодателей в 2022 году;

• возможность постоянного доступа к обновлениям тренинга;

• 6 проектов в портфолио;

• гарантированное трудоустройство или возврат денег.

Недостатки:

• медленные ответы кураторов на вопросы;

• не все темы снабжены домашними заданиями.

Программа обучения:

• Основы Python.

• Старт в DevOps: системное администрирование для начинающих

• DevOps-инженер. Основы

• DevOps-инженер. Advanced

• Система контроля версий Git

• Основы Python

• Язык запросов SQL

• Docker

Ознакомиться с полной программой >>>

6. ClickHouse для инженеров и архитекторов БД | Otus.ru

Уроки для тех, кто уже обладает базовыми знаниями SQL и Linux Авторы рассматривают ClickHouse от базовых концепций до продвинутых решений. Слушатели узнают, как установить и настроить, работать с базовыми и расширенными функциями, отличиями от других СУБД и использовать ее в различных сценариях.

• Стоимость: от 7700 рублей в месяц

• Длительность: 3 месяца

• Формат обучения: вебинары, домашние задания, тестирование

• Сертификат: да

Преимущества:

• практические задания для закрепления знаний;

• бесплатная консультация после сессий AMA и домашних заданий;

• прохождение тренинга в назначенное время или в индивидуальном темпе.

Недостатки:

• много теории на вебинарах;

• избыток домашних заданий.

Программа обучения:

• Знакомство с ClickHouse

• Работа с ClickHouse

• Масштабирование и манипуляции с данными

• Управление ресурсами

• Популярные интеграции

• Проектная работа

Ознакомиться с полной программой >>>

7. Microservices - паттерны | PurpleSchool

Для тех, кто стремится освоить архитектуру микросервисов, начиная с декомпозиции проекта и заканчивая реализацией бизнес-логики. Антон Ларичев, автор тренинга, предоставляет уникальный опыт внедрения микросервисов из реальных проектов. Студенты учатся работать с такими технологиями, как Docker, RabbitMQ, NestJS, и погружаются в асинхронную архитектуру. На фоне множества практических заданий тренинг дает не только знания по разработке TypeScript для Node.js, но и теоретическую основу для успешного внедрения микросервисов.

• Стоимость: от 2999 рублей

• Длительность: 14 часов

• Формат обучения: записи лекций, домашние задания, тестирование

• Сертификат: да

Преимущества:

• 30-дневная гарантия возврата денег;

• постепенное освоение материала от простого к сложному;

• поддержка опытного наставника;

• возможность добавлять проекты в портфолио;

• практический опыт разработки;

• последовательное изучение серверной разработки.

Недостатки:

• возможные трудности в организационных вопросах;

• ограниченное совместное обсуждение заданий с сокурсниками.

Программа обучения:

• Настройка окружения

• Нотация описания

• Монорепозитории

• Обмен сообщениями

• RabbitMQ

• Реализация взаимодействия

• Реализация API

• Реализация бизнес логики

• Консистентность данных

Ознакомиться с полной программой >>>

8. Enterprise Architect | Otus.ru

Разработанный для бизнес-аналитиков и системных аналитиков, архитекторов и лидеров цифровой трансформации, тренинг дает представление о всеобъемлющем взгляде на корпорацию. Преподаватели объясняют ключевые элементы метода разработки архитектуры TOGAF, обучая анализу компании на всех уровнях. Студенты узнают, как создавать, координировать и поддерживать целевое видение компании, а также адаптировать метод TOGAF к гибким организациям. Уроки направлены на преодоление разрыва между стратегией и реализацией, предоставляя современное понимание бизнес-архитектуры.

• Стоимость: от 7875 рублей в месяц

• Длительность: 4 месяца

• Формат обучения: онлайн-лекции, практические задания, итоговый проект

• Сертификат: да

Преимущества:

• вебинары с преподавателями-практиками;

• обучение на реальных примерах;

• возможность онлайн-обучения с записью вебинаров для пропущенных занятий;

• разработка собственного проекта;

• практика с экспертами из различных отраслей;

• мастер-классы;

• поддержка преподавателя-куратора.

Недостатки:

• длинные лекции, требующие больших временных вложений;

• сложные практические задания.

Программа обучения:

• Архитектура и стратегия

• Бизнес-архитектура

• Архитектура информационной среды

• Техническая архитектура

• Архитектурное исследование

• Управление архитектурой и реализацией изменений

• Развитие компетенций архитектора

Ознакомиться с полной программой >>>

9. Полный путь от монолита на Rails к микросервисной архитектуре | Thinknetica

В этой программе представлен полный путь от монолитного приложения Rails к архитектуре. Предназначен для тех, кто стремится освоить принципы построения микросервисов на Ruby, включая создание, тестирование и объединение их в единую систему. Автор Евгений Фатеев, RoR-разработчик с более чем 10-летним стажем, предоставляет уникальный опыт и конкретные инструменты для успешного внедрения микросервисов. Тренинг включает в себя теоретическую базу и практические навыки.

• Стоимость: от 35 900 рублей

• Длительность: 9 недель

• Формат обучения: скринкасты с уроками, домашние задания

• Сертификат: да

Преимущества:

• обучение от ведущих разработчиков и руководителей команд с большим опытом работы;

• уникальная информация;

• гарантия возврата денег в течение 14 дней;

• возможность применения лучших подходов и наработок в работе.

Недостатки:

• большая нагрузка во второй части тренинга;

• очень ограниченное время для заключительной проектной работы.

Программа обучения:

• Архитектура и принципы создания приложений

• Ruby-микросервисы

• Логирование

• Деплой

• Мониторинг

Ознакомиться с полной программой >>>

10. Микросервисная архитектура | IBS Training Center

Этот тренинг поможет вам принимать обоснованные решения о ее использовании в зависимости от потребностей бизнеса. Он рассматривает основные проблемы, механизмы и шаблоны для их решения, а также знакомит с такими инструментами, как Kubernetes и Istio. Практические занятия под руководством эксперта в области разработки программного обеспечения Александра Лавыша дают студентам практические навыки проектирования систем ISA. Тренинг предназначен для архитекторов, специалистов DevOps и ведущих разработчиков, предоставляя не только теоретические основы, но и реальные практические навыки проектирования и внедрения ISA.

• Стоимость: 48 900 рублей

• Длительность: 24 академических часа

• Формат обучения: онлайн-лекции, домашние задания

• Сертификат: да

Преимущества:

• широкий кругозор преподавателя обогащает учебный процесс;

• тренинг охватывает многие аспекты, включая примеры из реального мира;

• групповые задания.

Недостатки:

• лекции могут выходить за обещанные временные рамки;

• теоретическая база может быть не совсем полной.

Программа обучения:

• Архитектурные стили

• Паттерны декомпозиции MSA

• Организация разработки под MSA

• Интеграция

• Организация работы с данными в MSA

• Основные шаблоны МСА

• Развертывание

• Стратегии миграции от монолита к MSA

Ознакомиться с полной программой >>>

Бесплатные курсы по микросервисной архитектуре

Архитектура микросервисов — это инновационный подход к разработке программного обеспечения, который позволяет разработчикам эффективно организовывать свои усилия в рамках автономных команд. Каждая команда отвечает за разработку и поддержку одного или нескольких сервисов, действуя полностью независимо. Такая декомпозиция обеспечивает гибкость и ускоренную разработку, позволяя вам использовать различные технологические стеки при создании новых сервисов или внесении существенных изменений в существующие. Мы предлагаем бесплатные курсы по микросервисной архитектуре для начинающих, которые дают базовые практические знания для освоения этого подхода.

1. Что такое микросервисы от Maksim Zhashkevych

Этот видеотренинг на YouTube продолжительностью около полутора часов дает углубленный обзор теории архитектуры микросервисов. Ведущий, Максим Жашкевич, делится своим опытом. В видео раскрываются основные принципы архитектуры микросервисов, объясняется, как разделение приложения на автономные компоненты может ускорить разработку и сделать ее более гибкой и управляемой.

Основные характеристики:

• продолжительность: около 1,5 часов;

• принципы архитектуры микросервисов;

• применимость микросервисов для больших команд, сложных проектов, нестабильного трафика и частых обновлений приложений.

2. Микросервисная архитектура базовые знания от Laravel Creative

Видеоурок на YouTube продолжительностью около полутора часов дает базовые знания по архитектуре микросервисов. От введения в концепцию монолита до подробного рассмотрения плюсов и минусов микросервисов, тренинг обеспечивает четкое понимание основ этой архитектуры. Этот тренинг предназначен для начинающих разработчиков и тех, кто интересуется веб-разработкой. Он предоставляет базовые знания об архитектуре микросервисов, помогая студентам понять отличия от монолита и освоить основные принципы создания приложений в стиле микросервисов.

Основные характеристики:

• структурированный обзор: от введения до практического задания;

• анализ плюсов и минусов монолита и микросервисов;

• пример приложения с микросервисами;

• рекомендации и терминология архитектуры микросервисов.

3. Все про Микросервисы от Sergei Calabonga

Тренинг включает в себя обзор шаблонов, советов, правил, рекомендаций и решений для успешного внедрения микросервисной системы. Канал ориентирован на разработчиков и программистов, которые хотят стать архитекторами информационных систем. Он подходит как для тех, кто только начинает свой путь в программировании, так и для опытных разработчиков.

Основные характеристики:

• продолжительность: от полутора часов до получаса на видео;

• обширный охват: шаблоны, правила, рекомендации, решения;

• опытный руководитель: Сергей Калабонга — программист с опытом работы с 1989 года;

• новые элементы и темы: от ASP.NET до облачных шаблонов проектирования.

Заключение

Знакомство с архитектурой микросервисов открывает новые горизонты, позволяя вам эффективно разрабатывать, тестировать и масштабировать сервисы независимо друг от друга. Курсы микросервисной архитектуры предоставляют множество вариантов обучения с учетом таких критериев, как цена, опыт преподавателя, количество практики и другие важные параметры.

Больше курсов по микросервисной архитектуре смотрите в нашем каталоге.

Получив квалифицированную консультацию экспертов, выполнив практические задания и реальные проекты, вы сможете развить необходимые профессиональные навыки для успешного трудоустройства.

Сегодня порекомендую статью о структуре фронтенд проектов на основе вертикальных слайсов.

Автор начинает рассказ с описания структур первых проектов, где использовался подход “Разделения по техническим слоям”, в котором мы группируем файлы по функциональности, а не по доменной области:

- api/services
- components
- stores
- constants
- и т.д.

и затем описывается, как этот подход всё ещё используется внутри “вертикальных слайсов”.

Разделение по техническим слоям

✅ Плюсы подхода

- хорошо работает для маленьких проектов
- у слоев есть однонаправленный поток использования, и нельзя импортировать файлы из слоев, находящихся на уровне выше (например сторы могут использовать api, а страницы могут использовать базовые компоненты, но не наоборот).

❌ Проблемы подхода

- Даже для небольших продуктовых фичей приходится править код по всему проекту, так как он раскидан по разным папкам
- Неявные связи в рамках конкретных слоев: бизнес компоненты (ProductCard, UserProfile) смешиваются c UI компонентами (Link, Button) в components, то же самое касается бизнес логики

«Vertical sliced» подход

Подход подразумевает, что архитектура строится не вокруг технических слоев, а поверх конкретных слайсов проекта.

По сути, мы берём структуру “разделения по техническим слоям” и делаем разрез по фичам. То есть, создаём папку для каждой фичи, внутри которой все файлы относятся только к этой фиче и “разделены по техническим слоям”.

ℹ️ Описание папок

- shared - тут хранятся всё, что можно переиспользовать и не зависит от определённой бизнес фичи. Например в shared/components будут лежать, обычные кнопки, радио кнопки и прочее
- domain - базовый UI для бизнес-сущностей (домена) проекта, например карточка товара. Простая аналогия (но не совсем правильная) - в домене можно хранить все то, что хранится в базе данных на бекенде.
- features - самодостаточные компоненты — большие бизнес сущности приложения, например корзина. Для реализации фичи, скорее всего будет использоваться несколько компонентов из доменной области.
- pages - страницы приложения.

✅ Плюсы подхода

- Когда необходимо внести изменения в фичу — все изменения происходят внутри одного слайса.
- На выходе получаем высокое зацепление (high cohesion) внутри слайса и низкую связанность (low coupling) между разными слайсами
- Сохраняется правило однонапревленного использвания: pages ⇒ features ⇒ domain ⇒ shared
- Фичи не могут напрямую использовать друг друга
- На самом нижнем уровне используется “разделение по техническим слоям”

Чтобы обеспечить однонаправленный поток использования можно взять eslint c плагином import/no-restricted-paths.

https://t.me/cherkashindev/128