Download the PHP package bugover/ship without Composer

Porto (Архитектурный шаблон)

Добро пожаловать в Porto

• Вступление
• Приступая к работе
  • 1) Слой Корабля
  • 2) Слой Контейнеров
• Компоненты
  • 1) Основные компоненты
    • 1.1) Схема взаимодействия компонентов
    • 1.2) Жизненный цикл запроса
    • 1.3) Определения и принципы основных компонентов
      • Маршруты (Routes)
      • Контроллеры (Controllers)
      • Запросы (Requests)
      • Действия (Actions)
      • Задачи (Tasks)
      • Модели (Models)
      • Шаблоны (Views)
      • Преобразователи (Transformers)
      • Исключения (Exceptions)
      • Поддействия (Sub-Actions)
  • 2) Дополнительные компоненты
• Типичная структура контейнера
• Атрибуты Качества Porto
• Реализации (Построены на базе Porto)
• Обратная связь и вопросы

Вступление

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

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

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

Porto унаследовал концепции из DDD (Domain Driven Design), Modular, Micro Kernel, MVC (Model View Controller), Layered and ADR (Action Domain Responder) архитектур.
И он придерживается списка удобных принципов дизайна, таких как SOLID, OOP, LIFT, DRY, CoC, GRASP , Generalization, High Cohesion и Low Coupling.

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

Мы очень ценим отзывы и предложения.

"Простота является необходимым условием надежности.” — Эдсгер Дейкстра

Приступая к работе

Обзор слоев

По своей сути Порто состоит из 2-х слоев "папок" Контейнеры & Корабль.

Эти слои могут быть созданы в любом месте в любой выбранной структуре.

(Пример: в Laravel или Rails они могут быть созданы в app/ директории или в новой src/ директории в корне.)

Визуальный обзор

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

Уровни кода

• Низкоуровневый код: код фреймворка (реализует основные операции, такие как чтение файлов с диска или взаимодействие с базой данных). Обычно живет в каталоге поставщиков (vendors).
• Среднеуровневый код: общий код приложения (реализует функциональность, которая обслуживает код высокого уровня. И он полагается на низкоуровневый код для работы). Должен быть в слое "Корабль".
• Высокоуровневый код: код бизнес-логики (инкапсулирует сложную логику и для функционирования полагается на код среднего уровня). Должен быть в слое "Контейнеры".

Схема Слоев

Слой Контейнеров (грузовые контейнеры) >> опирается >> на слой Корабля (грузовой корабль) >> опирается >> на Фреймворк ( море).

От Монолита к Микро-сервисам

Porto создан, чтобы масштабироваться вместе с вами! В то время как большинство компаний переходят от монолита к микро-сервисам (и в последнее время без серверов) по мере их расширения. Porto предлагает гибкость, позволяющую превратить ваш монолитный продукт в микроуслуги (или SOA) в любое время с наименьшими возможными усилиями.

В терминах Porto Монолит это эквивалент одного грузового корабля с контейнерами, в то время как Микро-сервисы это эквивалент нескольких контейнерных кораблей. (Независимо от их размеров)

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

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

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

1) Слой Корабля

Слой "Корабль" содержит родительские "Базовые" классы (классы, расширяемые каждым отдельным компонентом) и некоторый Служебный Код.

Родительские классы «Базовые классы» слоя «Корабль» предоставляют полный контроль над Компонентами Контейнера (например, добавление функции к классу Базовой Модели делает его доступным в каждой Модели в ваших Контейнерах).

Слой «Корабль» также играет важную роль в отделении кода приложения от кода фреймворка. Это облегчает обновление Фреймворка, не затрагивая код приложения.

В Porto уровень «Корабль» очень тонкий, он НЕ содержит общих многоразовых функций, таких как Аутентификация или Авторизация, поскольку все эти функции предоставляются контейнерами, которые можно заменять по мере необходимости. Предоставляя разработчикам большей гибкости.

Структура Корабля

Уровень корабля содержит следующие типы кода:

• Код Ядра: это двигатель корабля, который автоматически регистрирует и автоматически загружает все компоненты вашего Контейнера для загрузки вашего Приложения. Он содержит большую часть магического кода, который обрабатывает все, что не является частью вашей бизнес-логики. И в основном содержит код, который облегчает разработку за счет расширения возможностей платформы.
• Общий код Контейнеров
  • Родительские классы: базовые классы каждого компонента в вашем контейнере. (Добавление функций в родительские классы делает их доступными в каждом контейнере). Родители созданы, чтобы содержать общий код для ваших Контейнеров.
  • Универсальные Классы: многоразовые функции и классы, которые могут использоваться каждым Контейнером. Например, глобальные исключения, миддлвары приложения, файлы глобальной конфигурации и т.д.

Примечание: Все компоненты контейнера ДОЛЖНЫ расширяться или наследоваться от уровня «Корабль» (в частности, от родительской папки).

При отделении Ядра в отдельный пакет Корабль-Родители должны расширять Ядро-Родителей (могут быть названы Абстрактными, поскольку большинство из них должны быть Абстрактными Классами). Корабль-Родители содержат общую бизнес-логику вашего пользовательского приложения, в то время как Ядро-Родители ( Абстрактные) содержат общий код вашей платформы, в основном все, что не является бизнес-логикой, должно быть скрыто от разрабатываемого приложения.

2) Слой Контейнеров

Porto управляет сложностью проблемы, разбивая ее на более мелкие управляемые контейнеры.

Слой Контейнеров - это место, где живет бизнес-логика приложения (Особенности приложения / функциональность). Вы будете проводить 90% своего времени на этом слое, создавая компоненты.

Вот пример того, как создаются Контейнеры:

"В приложении объекты "Задача", "Пользователь" и "Календарь" будут находиться в разных контейнерах, каждый из которых имеет свои собственные Маршруты (Routes), Контроллеры (Controllers), Модели (Models), Исключения ( Exceptions) и т.д. И каждый контейнер отвечает за получение запросов и возврат ответов от любого поддерживаемого пользовательского интерфейса (Web, API..)."

Рекомендуется использовать одну Модель для каждого Контейнера, однако в некоторых случаях вам может потребоваться больше, чем одна Модель, и это совершенно нормально. (Даже если у вас есть одна Модель, у вас также могут быть значения (Values) "также известные как Объекты-Значения (Value Objects)" (Values аналогичны моделям, но не представлены в базе данных в их собственных таблицах, а как данные в Моделях), эти объекты создаются автоматически после того как их данные извлекаются из БД, такие как Цена, Местоположение, Время ...)

Просто имейте в виду, что две Модели означают два Репозитория, два Преобразователя (Transformers) и т.д. Если вы не хотите всегда использовать обе модели вместе, разделите их на 2 контейнера.

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

Базовая структура Контейнеров

Взаимодействие Контейнеров и Связи

• Контейнер МОЖЕТ зависеть от одного или многих других контейнеров. (Желательно в том же разделе.)
• Контроллер МОЖЕТ вызывать задачи из другого контейнера.
• Модель МОЖЕТ иметь связь с моделью из другого контейнера.
• Возможны также другие формы связи, такие как Прослушивание Событий, запускаемых другими Контейнерами.

Если вы используете обмен данными между контейнерами на основе событий, вы можете использовать тот же механизм после разделения кодовой базы на несколько служб (сервисов).

Примечание. Если вы не знакомы с разделением кода на модули / домены или по какой-то причине не предпочитаете такой подход. Вы можете создать все свое приложение в одном контейнере. (Не рекомендуется, но абсолютно возможно).

Секции Контейнеров

Контейнерные "Секции" - еще один очень важный аспект в архитектуре Porto.

Думайте о секции как о рядах контейнеров на грузовом корабле. Хорошо организованные контейнеры в рядах, ускоряют погрузку и разгрузку связанных контейнеров для конкретного клиента.

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

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

Пример: если вы создаете гоночную игру, такую как Need for Speed, у вас могут быть следующие два раздела: Секция Гонки и Секция Lobby, где каждая секция содержит Контейнер Автомобиля и Модель Автомобиля внутри, но с разными свойствами и функциями. В этом примере Модель Автомобиля в Секции Гонки может содержать бизнес-логику для ускорения и управления автомобилем, в то время как Модель Автомобиля в Секции Lobby содержит бизнес-логику для настройки автомобиля перед гонкой.

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

Если вы предпочитаете простоту или у вас только одна команда, работающая над проектом, вы можете вообще не иметь Секций (где все контейнеры находятся в папке контейнеров), что означает, что ваш проект представляет собой одну Секцию. В этом случае, если проект быстро растет и вы решили, что вам нужно начать использовать Секции, вы можете создать новый проект также с одним разделом, это называется Микросервисами. В Микросервисах каждая секция «часть проекта» находится в своем собственном проекте (репозитории), и они могут обмениваться данными по сети, как правило, с использованием протокола HTTP.

Компоненты

На уровне Контейнера есть набор Компонентов "Классы" с предопределенными обязанностями.

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

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

Типы Компонентов

Каждый Контейнер состоит из нескольких компонентов, в Porto Компоненты разделены на два типа: Основные Компоненты и Дополнительные Компоненты.

1) Основные Компоненты

Вы должны использовать эти компоненты, поскольку они необходимы практически для всех типов веб-приложений:

Маршруты (Routes) - Контроллеры (Controllers) - Запросы (Requests) - Действия (Actions) - Задачи (Tasks) - Модели ( Models) - Представления (Views) - Преобразователи (Transformers).

Шаблоны: следует использовать в случае, если приложение обслуживает HTML-страницы.
Преобразователи (Transformers): следует использовать в случае, если приложение обслуживает данные JSON или XML.

1.1) Схема взаимодействия Основных Компонентов

1.2) Жизненный цикл Запроса

Базовый сценарий вызова API, навигация по основным компонентам:

1. Пользователь вызывает Endpoint в файле Маршрута.
2. Endpoint вызывает Посредника (Middleware) для обработки Аутентификации.
3. Endpoint вызывает соответствующий Контроллер .
4. Запрос внедренный в Контроллер автоматически применяет валидацию и правила авторизации.
5. Контроллер вызывает Действие (Action) передает ему данные Завпроса.
6. Действие (Action) выполняет бизнес-логику, *ИЛИ может вызывать столько Задач (Tasks), сколько необходимо для повторного использования подмножеств бизнес-логики.
7. Задачи (Tasks) выполняют многократно используемые подмножества бизнес-логики (Задача (Task) может выполнять единственную часть основного Действия (Action).
8. Действие (Action) подготавливает данные для возврата в Контроллер, некоторые данные могут быть собраны из Задач ( Tasks).
9. Контроллер создает ответ используя Представление (View) (или Преобразователь (Transformer)) и отправляет его назад Пользователю

1.3) Основные Компоненты, определения и принципы

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

2) Дополнительные Компоненты

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

Tests - Events - Listeners - Commands - Migrations - Seeders - Factories - Middlewares - Repositories - Criteria - Policies - Service Providers - Contracts - Traits - Jobs - Values - Transporters - Mails - Notifications...

Типичная Структура Контейнера

Контейнер со списком основных и дополнительных Компонентов.

Атрибуты качества Porto

Преимущества использования Porto.

Get in Touch

Your feedback is important.

For feedbacks, questions, or suggestions? We are on Slack.

Автор

Mahmoud Zalt Twitter: @mahmoudz Site: zalt.me

Русский перевод (примерный)

Dmitry N Github

Donations

Become a Github Sponsor.
Direct donation via Paypal.
Become a Patreon.

License

MIT © Mahmoud Zalt