L'histoire retient des couples légendaires : Roméo et Juliette, Bonnie and Clyde, le pâté et le saucisson... Je suis aujourd'hui convaincu que ROA et DDD ont leur place parmi ces couples légendaires.

Parmi les livres que j'ai lus cette année, c'est indiscutablement RESTful Web Services qui m'a le plus apporté. En deux mots, puisque ce n'est pas le sujet de ce billet, ce livre prône la simplicité en montrant que HTTP est suffisant pour créer des services web puissants sans ajouter de complexité inutile. Il introduit également Resource Oriented Architecture (ROA) qui est une approche pour créer des services web RESTful en mettant les ressources au coeur de l'architecture.

Plus je m'imprègne de ROA, plus je suis frappé par les parallèles qu'il est possible de faire avec DDD.

Des objets, encore des objets

Avec une conception orientée par le domaine (DDD), le paradigme objet est totalement utilisé. On pousse au maximum l'imbrication des données et des méthodes qui travaillent sur ces données. On cherche à modéliser le métier au travers de design patterns adaptés (stratégie, spécification, composite...). A contrario, les services (un objet qui fait plutôt qu'un objet qui est) doivent être utilisés avec parcimonie.

Il en est de même avec ROA. Cette approche s'oppose en effet à un style Remote Procedure Call (RPC) à la façon de SOAP, Corba et les autres. La procédure fait quelque chose et je me permet de citer le livre :

A resource is something, so I take an object-oriented approach to designing resouces. In fact, the resource-oriented design strategy could be called "extreme object-oriented."

Ah ! Qu'ils sonnent bien à mes oreilles ces deux termes mariés ensemble (je vous avais dit que je parlerai de couples légendaires).

Avec une architecture orientée services (SOA), ce sont les procédures qui sont mises en avant et il est alors légitime de vouloir y associer une approche RPC comme les WS-* (manière de désigner les gros services web à base de WSDL et de SOAP, qui n'a de simple que le nom).

ROA et DDD se marient parfaitement pour mettre en avant les entités et les objets du domaine.

URI et identité

En DDD, on reconnaît une entité car elle est identifiable. Deux entités différentes auront des identités différentes. HTTP s'appuie sur le même type de concept : l'identifiant uniforme de ressource (URI). Chaque ressource est ainsi identifiée de manière unique.

Il est également très important de ne pas confondre la ressource et son identifiant, pratique malheureusement largement répandu qui consiste par exemple à mélanger joyeusement la référence d'un client et le client lui-même. L'URI découle de la modélisation d'une ressource, pas l'inverse.

Associations et connectivité

Pour naviguer dans un graphe d'objets complexe, DDD incite à modéliser les relations qui existent entre les entités via des associations. Les entités sont connectées comme dans un grand réseau, oserai-je dire toile ? Ça y est j'ai osé ! La connectivité est ce qui a permis au Web de devenir aussi riche et populaire. Sans lien, chaque ressource serait condamné à vivre sa vie isolée des ressources qui lui sont voisines. Là encore DDD et ROA sont vraiment similaires.

Conclusion

Je n'ai fait qu'effleurer le sujet et je suis sûr qu'on peut trouver beaucoup d'autres similitudes entre ROA et DDD. Ces deux approches sont, à mon avis, très similaires et complémentaires. Elles sont basées sur la modélisation de la complexité tout en restant très simple. En parlant de simplicité, je ne résiste pas à l'envie de recopier la citation en préface du livre sus-cité :

A complex system that works is invariably found to have evolved from a simple system that worked.
John Gall, Systematics