[JAVA] Extension du modèle à 4 niveaux de l'architecture prônée par Eric Evans

Résumé de l'article

Eric Evans, le créateur de la conception axée sur le domaine, a proposé le modèle à quatre couches suivant dans le développement de programmes. ** ・ Couche de contrôle ・ ・ ・ Responsable de la connexion à l'application chez RestApi. ** ** ** ・ Couche de cas d'utilisation ・ ・ ・ Responsable de la logique métier de l'application. Les méthodes de la couche de domaine sont agrégées ici. ** ** ** ・ Couche de domaine: couche qui décrit le traitement commun. Appelez la couche de cas d'utilisation. ** ** ** ・ Couche d'infrastructure ・ ・ ・ Responsable de la logique technique qui dépend de bibliothèques externes telles que la messagerie et la connexion FTP. Appelé depuis une couche autre que la couche infrastructure. ** **

La conception axée sur le domaine est un concept préconisé au début de 2000. Depuis lors, la conception axée sur le domaine a évolué et de nouvelles méthodes de conception combinant des méthodes de couche de domaine telles que CQRS et l'approvisionnement d'événements ont vu le jour. L'expansion de la couche de domaine a saturé le modèle à quatre couches de l'architecture proposée par Eric Evans et compliqué la conception. Cet article vise à ajouter des couches de couches au ** modèle d'architecture à quatre couches ** pour rendre la conception pilotée par domaine plus sophistiquée et simple.

Ajouter une couche de mission qui regroupe les méthodes de la couche de domaine au modèle à 4 couches

Dans le développement piloté par les fonctionnalités, la méthode de couche de domaine est appelée par l'unité de fonction (plume) et la planification, la conception, le codage, les tests unitaires et la publication sont effectués. https://www.lucidchart.com/blog/why-use-feature-driven-development

En créant une classe de contour progressif qui agrège les méthodes de la couche domaine, elle agit comme un intermédiaire entre le cas d'utilisation et la couche et la couche domaine. Suivant le modèle de Feature Driven Development, nous proposons d'ajouter une ** couche mission ** qui agrège les méthodes de la couche domaine au ** modèle 4 couches **. Voici un diagramme de comparaison du ** modèle à 4 couches ** et du ** modèle à 5 couches ** avec la ** couche de mission ** ajoutée.

Effets secondaires causés par l'ajout d'une couche de mission au modèle à 4 couches

** La couche de domaine est isolée de la couche de cas d'utilisation ... Comme la couche de domaine est isolée de la couche de cas d'utilisation, l'influence du changement de couche de cas d'utilisation ne se propage pas à la couche de domaine. ** **

** Un espace pour décrire la logique du CQRS ou du sourcing d'événements peut être fourni ... Le CQRS ou le sourcing d'événements peut être décrit dans la couche mission, donc la visibilité de la logique est améliorée **

Direction du développement futur du modèle à 5 couches

Le cours suivant est prédit comme la direction du développement du ** modèle à 5 couches **.

** - Appliquer le concept d'architecture DCI à la couche mission afin qu'elle puisse répondre à un large éventail de demandes de la couche de cas d'utilisation ** https://qiita.com/aLtrh3IpQEnXKN7/items/355ad12f82ac424abea3

** ・ Hiérarchisez la couche de cas d'utilisation pour chaque niveau de requête et clarifiez la raison de l'appel de la méthode de la couche de mission ** https://qiita.com/aLtrh3IpQEnXKN7/items/853ecb3cd109dd016476