Une architecture propre vue par un développeur Python

La poursuite de l'élégance et le dynamisme puissant du langage ont créé de nombreuses bibliothèques avec une API vraiment délicieuse. 

Mauvais code

Architecture épurée

• La règle de priorité pour la couche intérieure - c'est la couche intérieure qui détermine l'interface par laquelle elle interagira avec le monde extérieur;
• Règle de dépendance - Les dépendances doivent être dirigées de la couche intérieure vers l'extérieur.

• Règle de passage des frontières;
• Règle de dépendance;
• La règle de priorité de la couche intérieure.

• Facilité de test - les couches sont isolées, respectivement, elles peuvent être testées sans patch de singe, vous pouvez définir granulairement le revêtement pour différentes couches, selon le degré de leur importance;
• Facilité de modification des règles métier , car toutes sont collectées en un seul endroit, ne sont pas réparties sur le projet et ne sont pas mélangées avec du code de bas niveau;
• Indépendance vis-à-vis des agents externes : la présence d'abstractions entre la logique métier et le monde extérieur permet dans certains cas de changer de sources externes sans affecter les couches internes. Cela fonctionne si vous n'avez pas lié la logique métier aux fonctionnalités spécifiques des agents externes, par exemple, les transactions de base de données;
• , , , .

, . . , . « Clean Architecture».

Python

from rentomatic.response_objects import response_objects as res

class RoomListUseCase(object):
   def __init__(self, repo):
       self.repo = repo
   def execute(self, request_object):
       if not request_object:
           return res.ResponseFailure.build_from_invalid_request_object(
               request_object)
       try:
           rooms = self.repo.list(filters=request_object.filters)
           return res.ResponseSuccess(rooms)
       except Exception as exc:
           return res.ResponseFailure.build_system_error(
               "{}: {}".format(exc.__class__.__name__, "{}".format(exc)))

repo RoomListUseCase, execute — . - , , . - . , , , repo .

from typing import Optional, List
from pydantic import BaseModel

class Room(BaseModel):
   code: str
   size: int
   price: int
   latitude: float
   longitude: float

class RoomFilter(BaseModel):
   code: Optional[str] = None
   price_min: Optional[int] = None
   price_max: Optional[int] = None

class RoomStorage:
   def get_rooms(self, filters: RoomFilter) -> List[Room]: ...

class RoomListUseCase:
   def __init__(self, repo: RoomStorage):
       self.repo = repo
   def show_rooms(self, filters: RoomFilter) -> List[Room]:
       rooms = self.repo.get_rooms(filters=filters)
       return rooms

def rool_list_use_case(filters: RoomFilter, repo: RoomStorage) -> List[Room]:
   rooms = repo.get_rooms(filters=filters)
   return rooms

from typing import List
from fastapi import FastAPI, Depends
from rentomatic import services, adapters
app = FastAPI()

def get_use_case() -> services.RoomListUseCase:
   return services.RoomListUseCase(adapters.MemoryStorage())

@app.post("/rooms", response_model=List[services.Room])
def rooms(filters: services.RoomFilter, use_case=Depends(get_use_case)):
   return use_case.show_rooms(filters)

, , , RoomStorage. , 15 , , , .

• Règle du franchissement des frontières: les modèles pydantiques, qui sont essentiellement des DTO, traversent les frontières ;
• Règle de dépendance : la couche de logique métier est indépendante des autres couches;
• La règle de priorité pour la couche interne : c'est la couche de logique métier qui définit l'interface (RoomStorage), à ​​travers laquelle la logique métier interagit avec le monde extérieur.