Architectures Back-End

Architecture en couches classique

[ Controller / API ]
                            |
                            [ Service / Domaine ]
                            |
                            [ Repository / ORM ]
                            |
                            [ DB / Cache ]

• Chaque couche a une responsabilité claire.
• Le domaine ne dépend pas des détails (framework, DB, HTTP).

Bonnes pratiques

• Pas d’accès direct à la DB depuis les contrôleurs.
• Regrouper les règles métier dans des services/domain.
• Interfaces pour les repos → facile à mocker en tests.

Anti-patterns

• “Fat controller” de 400 lignes.
• Requêtes SQL dispersées partout dans le code.
• Couche “service” qui ne fait que déléguer sans logique métier.

Concepts clés

• Ubiquitous language : vocabulaire partagé dev + métier.
• Bounded context : périmètre où ce langage est cohérent.
• Agrégat : ensemble cohérent avec un “root” qui protège les invariants.

Exemple de contextes

[ Billing ]    [ Orders ]    [ Catalog ]
                            |             |             |
                            factures   commandes    produits/prix

• Chaque contexte peut être un module ou un service.
• Les communications se font via événements ou APIs claires.

Exemple d’agrégat Order (pseudo-code)

class Order(AggregateRoot):
                            def add_item(self, product, qty):
                            # règle métier : pas plus de 50 lignes
                            if len(self.lines) >= 50:
                            raise MaxLinesExceeded()
                            self.lines.append(Line(product, qty))

Principe

      [ Port in ]
                        UI  / API / CLI
                        |
                        [ Domaine ]
                        |
                        DB / MQ / HTTP
                        [ Ports out ]

• Le domaine ne dépend pas des technologies externes.
• Les adapters (HTTP, DB, MQ, file) implémentent les ports.

Exemple port + adapter (pseudo Python)

class OrderRepositoryPort(Protocol):
                        def save(self, order: Order) -> None: ...
                        def find(self, id: str) -> Order | None: ...

                        class DjangoOrderRepository(OrderRepositoryPort):
                        def save(self, order):
                        OrderModel.from_domain(order).save()

                        # service reçoit OrderRepositoryPort, pas l'ORM

Cas d’usage

• Envoyer des emails / SMS après une commande.
• Synchroniser des données vers un data warehouse.
• Découpler actions lentes (facturation, PDF, export…).

Bonnes pratiques

• Messages immuables, auto-descriptifs (id, type, timestamp).
• Consommateurs idempotents (replay possible).
• Outbox pattern pour garantir la publication avec la transaction.

Exemple d’event (JSON)

{
                            "type": "order.created",
                            "id": "evt_123",
                            "occurred_at": "2025-12-01T10:00:00Z",
                            "data": {
                            "order_id": "ord_789",
                            "customer_id": "cus_456",
                            "total": 123.45
                            }
                            }

Patterns clés

• Timeouts partout (DB, HTTP, MQ).
• Retries avec backoff + jitter.
• Circuit breaker pour éviter les avalanches.
• Bulkheads pour isoler les ressources critiques.

Transactions & sagas

• Impossible de faire un 2PC global partout → utiliser des sagas.
• Saga orchestrée (service central) ou chorégraphiée (events).
• Compensations pour annuler les effets d’une étape.

Exemple pseudo-code “retry + timeout”

for attempt in range(3):
                            try:
                            with timeout(2.0):
                            return call_remote_service()
                            except TimeoutError:
                            sleep(backoff(attempt))
                            raise ServiceUnavailable()

SLO par service

• Uptime, latence P95/P99, taux d’erreur.
• Quota / limite pour éviter l’abus d’un consommateur.
• Dashboards par domaine (Orders, Billing, Auth…).

Instrumentation

• Logs structurés (JSON) avec trace_id & span_id.
• Métriques Prometheus : http_requests_total, db_latency_ms…
• Traces distribuées (OpenTelemetry).

Exemple métrique

http_requests_total{
                            service="orders-api",
                            route="/orders/{id}",
                            method="GET",
                            status="200"
                            } 12345

Approche pragmatique

• Stabiliser d’abord le monolithe (tests, métriques, modules).
• Identifier les “hotspots” : domaines à fort débit ou forte instabilité.
odule, pas tout le SI en une fois.

Strangler Fig Pattern

[ Client ]
                            |
                            [ API Gateway ]
                            |          \
                            [ Monolithe ]  [ Nouveau service Bounded Context ]

• On route progressivement certains endpoints vers les nouveaux services.
• Le monolithe se rétrécit jusqu’à pouvoir être retiré.

Anti-patterns de migration

• “Big bang rewrite” sans plan de rollback.
• Créer des microservices sans DDD ni bounded contexts.
• Multiplication des services “anémiques” avec peu de logique métier.

DDD & bounded contexts

• Ubiquitous language : même vocabulaire dev/métier.
• Bounded context : zone où ce langage reste cohérent.
• Chaque contexte = module fort ou microservice.

[ Orders ]   [ Billing ]   [ Catalog ]
                            commandes    factures       produits

Hexagonale / Clean architecture

• Domaine au centre, indépendant des frameworks.
• Ports (interfaces) et Adapters (implémentations techniques).
• Facilite les tests unitaires du domaine.

UI / API  -->  [ Application ]
                            |
                            [ Domaine ]
                            |
                            DB / MQ / HTTP clients

Exemple mix DDD + hexagonal (pseudo-code)

class OrderService:
                            def __init__(self, repo: OrderRepoPort, bus: EventBusPort):
                            self.repo = repo
                            self.bus = bus

                            def place_order(self, cmd: PlaceOrder):
                            order = Order.from_cmd(cmd)
                            order.validate_invariants()
                            self.repo.save(order)
                            self.bus.publish(OrderPlaced(order_id=order.id))

Événements & queues

• Découplage fort : producer & consumer ne se connaissent pas.
• Exemples : Kafka, RabbitMQ, SQS, Pub/Sub…
• Outbox pattern pour publier avec la transaction locale.

{
                            "type": "user.registered",
                            "id": "evt_123",
                            "occurred_at": "2025-12-08T10:00:00Z",
                            "data": { "user_id": "u42", "email": "x@y.z" }
                            }

Sagas & cohérence distribuée

• Saga orchestrée : un orchestrateur appelle les services un par un.
• Saga chorégraphiée : chaque service réagit à des events.
• Compensation : opérations “inverse” en cas d’échec de l’étape n.

createOrder
                            ├── reserveStock
                            ├── authorizePayment
                            └── confirmOrder
                            # si payment KO → releaseStock + cancelOrder

Patterns de résilience

• Timeouts sur chaque appel externe (DB, HTTP, MQ).
• Retries avec backoff + jitter, seulement sur erreurs transitoires.
• Circuit breaker pour couper un service en panne.

for attempt in range(3):
                            try:
                            with timeout(2.0):
                            return call_remote()
                            except Timeout:
                            sleep(backoff(attempt))
                            raise ServiceUnavailable()