L'architecture à l'oignon par opposition à L'Architecture à couches en N
une chose à l'avance: j'arrive d'un fond en couches.
j'ai maintenant passé beaucoup de temps à me concentrer sur L'Architecture de L'oignon et sur les concepts connexes axés sur les domaines, comme L'Architecture hexagonale, pour lire des ressources comme Jeff de Palerme série de billets de blog,Marque Seemann de la contribution d'un DI-point de vue,"Oignon-izing votre achitecture" et "Le propre de l'architecture".
tout Ce que ces articles ont en commun de revendiquer les points suivants:
- l'Accent est maintenu autour du modèle de domaine de l'entreprise en cas d'utilisation
- relâcher le couplage entre les couches en mettant l'accent sur le principe de L'Inversion de dépendance
- indépendance accrue des infrastructures externes telles que les cadres, la persistance des données, L'IU
- Meilleure testabilité / maintenabilité
Eh bien, tout cela semble incroyablement agréable et ceux les diagrammes regard doux. Mais la question qui se pose pour moi: tout cela n'est-il pas obtenu en ajoutant simplement des façades à mon architecture traditionnelle en n couches?
- chaque couche connaît juste les abstractions de la couche en dessous de
- les implémentations concrètes peuvent être maintenues à l'intérieur de chaque couche et sont donc au même endroit que les abstractions
- les détails d'implémentation peuvent être facilement échangés puisqu'ils sont internes à la couche et devraient ne pas affecter le reste de l'application
Aidez-moi à comprendre les véritables avantages d'une architecture axée sur les domaines.
Merci d'avance!
4 réponses
L'ajout de façades est en fait la première étape dans la construction d'une architecture oignon à partir d'une architecture en n couches. Donc, oui, vous pouvez obtenir de nombreux avantages.
Tester est toujours problématique car vous devez inverser le contrôle de la dépendance. Contrôler ce qui a la façade pointe vers le besoin de passer au consommateur, pas le fournisseur. Cela permet au consommateur d'échanger des choses pour des tests, ou pour modifier des implémentations sans que le fournisseur n'ait à savoir il.
bien que ce soit une question très ancienne, mais voudrait ajouter quelque chose.
cet article explique clairement pourquoi les couches ne sont pas préférables mais si vous avez mis en œuvre le CIO correctement, cela ne fera aucune différence.
je partage la même opinion que la vôtre, nous prévoyons de lancer un nouveau projet et un de mes collègues a suggéré l'architecture oignon, mais après avoir un peu documenté à ce sujet, j'étais un peu confus, parce que (pour moi!) le fait que chaque couche client doit dépendre uniquement de l'abstraction de la couche utilisée est une question de meilleure pratique qui doit toujours être à l'esprit quelle que soit l'architecture que nous envisageons d'utiliser, DI est un" principe " pas une architecture donc je ne pouvais pas réaliser à quel point utiliser l'architecture en n couches avec de "bons principes OO" en font une nouvelle architecture?
de cette façon, nous finirons par des centaines de nouvelles architectures simplement en combinant tous les principes OO et les modèles Go4 aux Architectures D'applications D'Entreprise.
pour répondre directement à votre question: "tout cela n'est-il pas obtenu en ajoutant simplement des façades à mon architecture traditionnelle en n couches?". La réponse est oui, et non, selon votre cas d'utilisation.
l'accent de L'architecture Onion sur l'utilisation de l'inversion de dépendance est comme vous l'avez dit... "créer un couplage lâche". Cependant, ce n'est pas seulement pour le couple perdant. Il pourrait être utile de penser à cela comme "protéger les parties de votre code qui sont les moins susceptibles de changer, à partir de parties qui sont plus susceptibles de changer". Donc, dans votre cas, est-ce que les changements "en dessous" de la façade nécessiteraient des changements à votre code "de domaine"? Est-ce qu'un changement à, disons, un objet de base de données, se répercuterait dans des changements à un objet utilisé dans la façade et puis dans votre "domaine" code? Si la réponse à ces questions est "non", alors votre hypothèse est correcte, il n'y a pas de véritable différence fonctionnelle pour ce code. Si quelqu'un devait répondre "peut-être", alors il pourrait bénéficier d'un remaniement des façades au CIO.