Слоистая архитектура – это подход к построению приложений, который разделяет код на отдельные слои, чтобы обеспечить более чистую и удобную структуру проекта. В данном случае мы будем рассматривать слоистую архитектуру для Backend приложений на FastAPI, соблюдая принципы чистой архитектуры.
FastAPI – это современный фреймворк для создания веб-приложений на Python, который обеспечивает высокую производительность и простоту в использовании. Он поддерживает асинхронное программирование и предоставляет удобный API для создания RESTful API.
Чистая архитектура – это методология разработки программного обеспечения, которая делает код более модульным, гибким и легко расширяемым. Она предполагает разделение кода на отдельные слои с явными зависимостями между ними.
Давайте рассмотрим основные слои в нашей слоистой архитектуре для Backend приложений на FastAPI:
-
Слой представления (Presentation Layer):
Этот слой содержит логику обработки запросов и формирования ответов. В FastAPI это можно реализовать с использованием маршрутов (routes) и зависимостей (dependencies). -
Слой бизнес-логики (Business Logic Layer):
В этом слое содержится вся бизнес-логика приложения. Здесь выполняются различные операции с данными и принимаются решения на основе бизнес-правил. -
Слой доступа к данным (Data Access Layer):
Этот слой отвечает за взаимодействие с базой данных или другими источниками данных. Здесь могут быть реализованы методы для чтения, записи и обновления данных. - Слой инфраструктуры (Infrastructure Layer):
В этом слое содержатся все вспомогательные классы и функции, которые используются для работы приложения. Сюда входят классы для работы с файлами, кэшированием, логгированием и т.д.
Теперь давайте создадим пример слоистой архитектуры для Backend приложения на FastAPI:
- Создадим файл main.py и определим в нем основные маршруты и зависимости для нашего приложения:
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
async def read_root():
return {"Hello": "World"}
- Создадим файл router.py, в котором определим слой представления:
from fastapi import APIRouter
router = APIRouter()
@router.get("/items/")
async def read_items():
return {"items": [{"item_id": "1", "name": "item1"}, {"item_id": "2", "name": "item2"}]}
- Создадим файл service.py, в котором определим слой бизнес-логики:
class ItemService:
def get_items(self):
return [{"item_id": "1", "name": "item1"}, {"item_id": "2", "name": "item2"}]
- Создадим файл repository.py, в котором определим слой доступа к данным:
class ItemRepository:
def get_items(self):
return [{"item_id": "1", "name": "item1"}, {"item_id": "2", "name": "item2"}]
- Создадим файл dependencies.py, в котором определим зависимости для нашего приложения:
from service import ItemService
from repository import ItemRepository
item_service = ItemService()
item_repository = ItemRepository()
- Внедрим зависимости в наши маршруты и определим их вызовы:
from fastapi import APIRouter
from dependencies import item_service
router = APIRouter()
@router.get("/items/")
async def read_items():
return item_service.get_items()
Таким образом, мы создали слоистую архитектуру для нашего Backend приложения на FastAPI, соблюдая принципы чистой архитектуры. Каждый слой отвечает за свою область ответственности и имеет явные зависимости от других слоев. Это делает код более структурированным, понятным и легко расширяемым.
шаблон очень полезный получился, но не по чистой архитектуре, будем честны)
Мне зашло, спасибо
Контент в кайф, можна вот етого вот по чаще)
привет, допустим мне нужно сделать какую то не обычную бизнес логику, мне ее писать в отдельном сервисе? а потом в юскейсе писать что если этот сервис вернул истину то вызываю например другой сервис, так лучше делать?
Не делай видосы о архитектуре, если ты не шаришь. Зачем выделять интерфейс под интерактор? Нету смысла. Чем у тебя является репозиторий? Это вообще не то, что подразумевают под патерном репозиторий.
Репозиторий – хранилище. Юзкейс должен представлять из себя простой сценарий, управление сценариями предоставляет интерактор