diff --git a/README.md b/README.md index aaba2fa1e..0c6c2c27b 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Website -This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator. +This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator. ### Installation diff --git a/versioned_docs/version-12.x/architecture-concepts/porto.md b/versioned_docs/version-12.x/architecture-concepts/porto.md index 2eed50c8d..67b028d5c 100644 --- a/versioned_docs/version-12.x/architecture-concepts/porto.md +++ b/versioned_docs/version-12.x/architecture-concepts/porto.md @@ -1,114 +1,34 @@ --- sidebar_position: 1 -title: Porto -tags: - - architecture - - porto +title: Porto SAP --- -[Porto SAP](https://mahmoudz.github.io/Porto/) is a modern software architectural pattern -that offers developers a comprehensive set of guidelines, -principles, and patterns to organize their code in a highly maintainable and reusable way. -The primary goal of Porto is to help developers create software that is scalable, -flexible, and easy to maintain over time. [Read more](https://mahmoudz.github.io/Porto/docs/Intro). +Apiato is built on the [**Porto SAP**](https://mahmoudz.github.io/Porto/) architectural pattern, a design specifically crafted to enhance scalability, maintainability, and reusability. By adopting Porto, Apiato provides a structured, modular way to organize code, which helps developers scale from a simple monolithic setup to complex microservices as the application grows. -## Layers +### What is Porto SAP? -Porto's architecture is based on two layers: Containers and Ship. +Porto SAP (Service Architecture Pattern) is a software architecture designed to bring clarity and structure to large applications. It introduces a well-defined organization for code, divided into two primary layers: -### Containers -The Containers layer encompasses all the application's business logic code and consists of two primary concepts: -- Section -- Container +- **Containers Layer**: Houses the core business logic and functionality, with components grouped into modular, independent sections. +- **Ship Layer**: Acts as the foundation, holding shared infrastructure, utilities, and configuration files accessible across Containers. -#### Section -A Section refers to a collection of related Containers. -These Containers can represent various entities such as services -(either micro or larger in scale) or subsystems within the main system. +Porto emphasizes modularity and clean separation of concerns, ensuring each part of the application remains maintainable and reusable. -:::note -A Section is not allowed to directly communicate with another Section, except via Events or Commands. -::: +### Understanding the Full Porto Architecture -#### Container -A Container represents a cohesive set of related functionalities. -It can be a specific feature or a wrapper around a RESTful API resource. +For a thorough understanding of Porto's structure and benefits, it’s recommended to explore the [Porto Documentation](https://mahmoudz.github.io/Porto/docs/Intro/). The documentation covers essential concepts like: +- **Layers and Components**: A deep dive into the Containers and Ship layers, as well as core components (Routes, Actions, Models, Tasks, and more). +- **Architectural Principles**: Learn about the foundational principles Porto follows, such as SOLID, Domain-Driven Design (DDD), and MVC, that enhance Apiato's architecture. +- **Scalability and Maintainability**: Insights into how Porto’s modular approach helps you build applications that can grow and adapt to changing requirements. -:::note -A Container is allowed to depend on other Containers in the same Section. -::: +Understanding the Porto architecture is highly recommended for anyone developing with Apiato, as it offers a clear blueprint for creating scalable, manageable applications. -### Ship -The Ship layer contains the infrastructure code, which consists of shared code utilized by all Containers. +### Layers Diagram -## Typical Project Structure -```markdown -app -├── Containers -│ ├── Section -│ │ └── Container -│ │ ├── Actions -│ │ ├── Configs -│ │ ├── Data -│ │ │ ├── Factories -│ │ │ ├── Migrations -│ │ │ ├── Repositories -│ │ │ └── Seeders -│ │ ├── Mails -│ │ │ └── Templates -│ │ ├── Middlewares -│ │ ├── Models -│ │ ├── Notifications -│ │ ├── Providers -│ │ ├── Tasks -│ │ ├── Tests -│ │ ├── Traits -│ │ └── UI -│ │ ├── API -│ │ │ ├── Controllers -│ │ │ ├── Requests -│ │ │ ├── Routes -│ │ │ └── Transformers -│ │ ├── WEB -│ │ │ ├── Controllers -│ │ │ ├── Requests -│ │ │ ├── Routes -│ │ │ └── Views -│ │ └── CLI -│ │ └── Commands -│ └── Vendor `// All installed and reusable Containers` -│ ├── ContainerA -│ └── ContainerB -└── Ship `// All shared code between all Containers` - ├── Broadcasts - ├── Commands - ├── Configs - ├── Contracts - ├── Criterias - ├── Events - ├── Exceptions - ├── Generators - ├── Helpers - ├── Kernels - ├── Listeners - ├── Mails - ├── Middlewares - ├── Migrations - ├── Notifications - ├── Parents - ├── Providers - ├── Seeders - └── Tests -``` -## Default Sections -Apiato ships with two default Sections: -- **AppSection**: contains all the default Containers. -- **Vendor**: contains all the installed and reusable Containers. + Laradock: Full PHP development environment on Docker. -:::tip -The **Vendor** section is a special Section within the Containers layer that holds installed and reusable Containers. -It serves a similar purpose as the vendor folder located at the root. -Any Section is permitted to depend on the Vendor Section, allowing for the utilization of its Containers. -Read more about the [Container Installer](../pacakges/readme.md) to learn how to install Vendor Containers. -::: + +### Components Diagram + + Laradock: Full PHP development environment on Docker. diff --git a/versioned_docs/version-12.x/architecture-concepts/request-lifecycle.md b/versioned_docs/version-12.x/architecture-concepts/request-lifecycle.md index 165432e4b..16465a31d 100644 --- a/versioned_docs/version-12.x/architecture-concepts/request-lifecycle.md +++ b/versioned_docs/version-12.x/architecture-concepts/request-lifecycle.md @@ -28,109 +28,3 @@ while the `Action` executes the business logic. The `Tasks` can be used to execute reusable subsets of the business logic, with each `Task` responsible for a single portion of the main `Action`. The `View` or `Transformer` is used to build the response that is sent back to the User. - -## Request Lifecycle Diagram - -[//]: # "TODO: Update the diagram to reflect the new architecture, specially after adding DTOs. API, Web and CLI can use the same Actions and DTOs, but the Controllers and Requests are different." - -#### Legend: - -- Solid Line: Mandatory dependency (always used) -- Doted Line: Optional dependency (not always used) -- Red Solid Border: Response generation -- Green Dashed Border: Optional component (not always used) - -```mermaid -graph TD - classDef dashedBorder stroke:#0f0,stroke-dasharray: 5 5; - classDef response stroke:red,stroke-width:2px; - subgraph Container - WebRoute[Web Route] - WebMiddleware[Middleware] - WebRequest[\Request/] - WebController{Controller} - WebAction[Action] - - CLI[CLI] - Command - CLIAction[Action] - - SubAction[SubAction] - - APIRoute[API Route] - APIMiddleware[Middleware] - APIRequest[\Request/] - APIController{Controller} - APIAction[Action] - - TaskA[Task] - TaskB[Task] - TaskC[Task] - TaskD[Task] - TaskE[Task] - - Job[Job] - - View[\View\]:::response - Transformer[/Transformer/]:::response - - RepositoryA[Repository] - RepositoryB[Repository] - - ModelA[Model] - ModelB[Model] - - ValueObject[Value Object] - - Event[Event] - ListenerA[Listener] - ListenerB[Listener] - end - - WebRoute[Web Route]-->WebMiddleware - WebMiddleware-->WebRequest - WebRequest-->WebController - WebController-->View - WebController<-->WebAction - WebAction<-..->TaskA{{Task}} - WebAction<-.->SubAction - - APIRoute[API Route]-->APIMiddleware - APIMiddleware-->APIRequest - APIRequest-->APIController - APIController<-->APIAction - APIController-->Transformer - APIAction<-..->TaskD{{Task}} - APIAction<-..->TaskE{{Task}} - APIAction-.->Job:::dashedBorder - - CLI[CLI]---->Command[[Command]] - Command-->CLIAction - CLIAction<-.->SubAction:::dashedBorder - CLIAction<-..->TaskD{{Task}} - - SubAction<-.->TaskB{{Task}} - SubAction<-.->TaskC{{Task}} - - TaskA-.-RepositoryA[(Repository)]:::dashedBorder - TaskB-.-RepositoryA[(Repository)]:::dashedBorder - TaskC-.-RepositoryB[(Repository)]:::dashedBorder - TaskD-.-RepositoryB[(Repository)]:::dashedBorder - - RepositoryA-.-ModelA - RepositoryB-.-ModelB - - ModelA(((Model)))-.-ValueObject[/ValueObject\]:::dashedBorder - ModelB(((Model)))-.-ValueObject[/ValueObject\]:::dashedBorder - - TaskE-.->Event:::dashedBorder - Event-.-ListenerA([Listener]):::dashedBorder - Event-.-ListenerB([Listener]):::dashedBorder - - Web--request-->Framework - Mobile--request-->Framework - etc[etc...]--request-->Framework - Framework-->WebRoute((Web Route)) - Framework-->CLI((CLI)) - Framework-->APIRoute((API Route)) -``` diff --git a/versioned_docs/version-12.x/consulting.md b/versioned_docs/version-12.x/consulting.md index 126666635..c2639bb69 100644 --- a/versioned_docs/version-12.x/consulting.md +++ b/versioned_docs/version-12.x/consulting.md @@ -1,5 +1,5 @@ --- -sidebar_position: 9 +sidebar_position: 200 title: Consulting ---