De l'architecture en couches au DDD. Mon expérience de migration et de découpe d'un monolithe

Aujourd'hui, nous allons parler de l'architecture des applications backend et comparer deux manières populaires de structurer des projets : l'oignon et le DDD. Je vais vous parler des avantages de la deuxième approche par rapport à la première et de mon expérience récente de transfert d'un projet vers une architecture hexagonale. Ce texte s'adresse à ceux qui ont déjà travaillé avec une architecture en couches et qui en veulent plus (par exemple, commencer à travailler avec des microservices).

Commençons par l'architecture en couches. En couches, également connue sous le nom d'architecture en oignon, est une architecture dans laquelle nous divisons l'ensemble de l'application en couches. Chaque couche a sa propre fonction, son propre objectif clair. Par exemple, l'interaction avec la base de données : une telle couche doit contenir exclusivement des fonctions d'interaction avec la base de données, et rien d'autre. Il ne devrait y avoir aucune interaction avec le client ou toute autre fonction.

Souvent, dans une architecture en couches, il y a 3 couches principales sur le backend : pour l'interaction avec le stockage, la logique applicative et une couche représentative.

Voici une architecture typique à trois couches, tout y est assez simple. La demande traverse toutes les couches, acquérant la forme finale (demande dans le stockage), la réponse fait le voyage de retour, se transformant en un format pratique pour le client (JSON, XML, etc.).

J'utilise cette architecture depuis assez longtemps dans tous mes projets et dans la startup à laquelle je participe. Dans les petits projets familiers, cette approche fonctionne vraiment et ne pose pas de problèmes, mais dans les projets plus importants, le chaos commence.

L'un des principes fondamentaux de l'architecture en couches est la possibilité de remplacer n'importe quelle couche par une couche similaire afin qu'aucune autre couche n'ait besoin d'être modifiée. Mais en réalité, plus il y a d'entités dans un projet, plus il est difficile de s'y conformer.

Au début, trop de dépendances apparaissent, et il devient de plus en plus difficile de les contrôler. Cela implique de négliger le monolithe (après tout, l’oignon est une architecture monolithique). La charge n'est pas répartie correctement et l'application est en surcharge. De plus, les couches commencent à se mélanger - il devient de plus en plus difficile d'isoler la logique applicative. Il devient de plus en plus difficile d’étendre l’application, les dépendances rendent le débogage un enfer et le développement ralentit considérablement. Les modèles architecturaux stricts qui limitent les capacités du développeur ajoutent de l'huile sur le feu. Si vous lisez ce texte, vous avez probablement déjà rencontré cela. La même situation s'est produite dans notre projet.

Évidemment, dans une telle situation, il faut couper le monolithe, passer à une autre architecture et introduire des modèles plus libres. Nous avons choisi DDD, cela nous semblait une solution évidente. DDD (Domain Driven Design, architecture hexagonale) est une architecture de microservice (bien qu'elle puisse être utilisée comme monolithique) construite sur des abstractions. Si vous n'avez qu'une expérience de travail avec une architecture en couches, alors à titre d'exemple approximatif, vous pouvez imaginer la même architecture à trois couches, où au lieu d'une couche d'interaction avec le stockage, il y a une couche d'interaction avec toutes les technologies en général, et il y a aussi un calque séparé avec des abstractions. Les abstractions sont généralement la chose principale dans DDD. Ces abstractions, ainsi que les outils auxiliaires et entités de démonstration (modèles, diagrammes) sont séparés de l'application, et par conséquent l'architecture ressemble à ceci :

Le principal avantage de l'architecture heskagonale par rapport à l'architecture en couches est l'extensibilité. Il est beaucoup plus facile d'implémenter de nouvelles fonctionnalités, de nouveaux paramètres et de nouvelles fonctions car il y a moins de dépendances.

Au début, cette structure me paraissait complètement illogique, mais en passant à DDD, j'ai découvert qu'elle devenait beaucoup plus facile à écrire, car l'infrastructure était complètement supprimée même de la couche la plus basse de l'application, et là il y avait moins de dépendances. Il y avait même une sorte de soulagement irrationnel et une soudaine liberté d’action sur chaque entité. Cette approche me semble désormais encore plus logique que l'architecture en couches.

Mais vous devez vous rappeler qu'une telle architecture n'a pas de sens s'il y a 2-3 entités dans le projet, car DDD est principalement utilisé comme architecture de microservice dans des applications avec un grand nombre de dépendances, qui ne peuvent tout simplement pas être dans petits projets pour animaux de compagnie avec 2-3 entités 3 essences. Dans certains endroits, même une simple architecture linéaire suffit. Et en général, utiliser ainsi différentes technologies et pratiques, inutilement, est une mauvaise pratique, à moins que vous ne décidiez d'expérimenter pour apprendre.

P.S. Et il faut devenir accro à TGC : https://t.me/dmkjfss

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!