BT

Présentation de l’Architecture IODA

| par Jan Stenberg Suivre 29 Abonnés , traduit par Slim Ouertani Suivre 6 Abonnés le 18 juin 2015. Durée de lecture estimée: 2 minutes |

Pour Ralf Westphal, les modèles d’architectures communs comme l'architecture en couches, l'architecture hexagonale et l'architecture Clean semblent tous très similaires lorsqu'ils effectuent les 2 actions suivantes : la définition des domaines de responsabilité et la mise des dépendances fonctionnelles dans l'ordre. Pour lui, ces modèles donnent une idée très grossière de la structure d’une application, décrivant essentiellement les logiciels comme une hiérarchie profonde de dépendances fonctionnelles ou comportementales.

À la recherche d’une autre manière de décrire les architectures, Westphal a défini un style architectural, IODA architecture, construit autour de trois responsabilités formelles, allant d'orthogonales à comportementales :

Opération : élément de la logique ou du changement comportemental sur les données, mais sans connaissance de toute autre opération et non autorisé à y faire appel.
Données : structure de données, incluant éventuellement des services travaillant sur ​​les données pour assurer la cohérence, mais sans addition de toute autre forme de logique.
Intégration : fait appel aux opérations et aux autres intégrations afin de mettre le tout en un ensemble créant ainsi un comportement, mais ne contiennent pas de logique.
APIs et frameworks constituent la quatrième partie grâce à travers laquelle les opérations interagissent avec l'environnement.

Dans ce modèle, les opérations dépendent uniquement sur des données, alors que les intégrations dépendent des opérations et d'autres intégrations. Par la présente, Westphal prétend avoir supprimé toutes les dépendances fonctionnelles, ce qui reste est simplement ce qu'il appelle des dépendances formelles ou vides. Il affirme également que puisque les opérations ne peuvent pas faire appel à d'autres opérations, extraire la logique de nouvelles méthodes opérationnelles implique la création d'intégrations afin de garder les choses ensemble et ainsi la mise en application de petites méthodes, moins de 10-20 lignes de code, dans une application.

Un aspect important que mentionne Westphal est qu’une structure IODA peut apparaître sur plusieurs niveaux. Ce qui est une opération pour un niveau d'abstraction peut-être en soi une structure complète IODA lorsque vous zoomez.

Westphal a créé un exemple de conception et de mise en œuvre d'une petite application utilisant IODA, incluant une description des idées de base derrière la conception avec les sources disponibles en téléchargement.

Evaluer cet article

Pertinence
Style

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Pas de miracle by Erik Gollot

On ne résout pas des problèmes de dépendances fonctionnelles par des entourloupes techniques. On peut en donner l'illusion mais fondamentalement on ne peut pas. On peut faire des interfaces génériques qui laissent passer les choses mais derrière la sémantique va devoir être prise en compte. J'ai côtoyé des frameworks de la sorte et bonjour le problèmes d'intégration et de documentation et compréhension des interfaces !!

Comment dire... non... by Jérôme Avoustin

Ouais... bon... on ne veut pas empiler des couches, et on se retrouve à empiler des intégrations... C'est une pure arnaque, puisque, selon le schéma, ce n'est ni plus ni moins que de l'archi en couche.
Evidemment, on oublie les principes DDD, notamment les Bounded Context, ce qui aura pour conséquence inévitable un bon vieux plats de spaghettis dans les dépendances des intégrations entre elles.
Non, les archis Clean ou Hexagonale n'ont, pour moi, que peu de sens si elles ne sont pas là pour supporter une approche centrée sur le domaine. Ce ne sont pas des archis auto-suffisantes. Donc les critiquer en tant que telles me parait incongru.

Re: Comment dire... non... by Erik Gollot

Tout à fait d'accord
Le nerf de la guerre c'est le fonctionnel et donc les Bounded Context
Comme toi je ne vois pas la différence avec l'archi en couches, on a juste changé les noms

Re: Comment dire... non... by Erik Gollot

J'avais pas vu ta dernière phrase. Oui les architectures en couches ne se suffisent pas à elles mêmes. Mais quand je vais un phrase "il a supprimé toutes les dépendances fonctionnelles" là je réagit...

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

4 Discuter

Se connecter à InfoQ pour interagir sur ce qui vous importe le plus.


Récupérer votre mot de passe

Follow

Suivre vos sujets et éditeurs favoris

Bref aperçu des points saillants de l'industrie et sur le site.

Like

More signal, less noise

Créez votre propre flux en choisissant les sujets que vous souhaitez lire et les éditeurs dont vous désirez suivre les nouvelles.

Notifications

Restez à jour

Paramétrez vos notifications et ne ratez pas le contenu qui vous importe

BT