BT

Accueil InfoQ Actualités Présentation de l’Architecture IODA

Présentation de l’Architecture IODA

Favoris

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

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

Commentaires de la Communauté

  • Pas de miracle

    by Erik Gollot /

    Ce message a été marqué comme possible SPAM. Un modérateur le relira et le publiera sans notification dans les 24 heures. Merci.

    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 /

    Ce message a été marqué comme possible SPAM. Un modérateur le relira et le publiera sans notification dans les 24 heures. Merci.

    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 /

    Ce message a été marqué comme possible SPAM. Un modérateur le relira et le publiera sans notification dans les 24 heures. Merci.

    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 /

    Ce message a été marqué comme possible SPAM. Un modérateur le relira et le publiera sans notification dans les 24 heures. Merci.

    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

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

BT

Votre profil est-il à jour? Merci de prendre un instant pour vérifier.

Note: en cas de modification de votre adresse email, une validation sera envoyée.

Nom de votre entreprise:
Rôle dans votre entreprise:
Taille de votre entreprise:
Pays/Zone:
État/Province/Région:
Vous allez recevoir un email pour confirmer la nouvelle adresse email. Ce pop-up va se fermer de lui-même dans quelques instants.