Devops for Growth

L'homéostasie n'est évidemment pas propre à l'être humain, et il est naturel d'étendre le concept à tout organisme vivant. Ce n'est toutefois qu'à partir du milieu du XXe siècle que le concept sera intégré à une réflexion bien plus générale.
En effet, c'est dans l'après-guerre que se développent des sciences abordant les systèmes complexes. Auparavant, l'approche quasi-unique des scientifiques était le réductionnisme : tout système complexe étant composé d'éléments simples, il semble évident que la compréhension du système global passe par la compréhension de ces éléments. Désormais, une autre approche, complémentaire, apparaît : la systémique.
L'idée principale de la systémique est qu'un tout est plus que la somme de ses parties, et les propriétés d'un système complexe sont parfois difficilement prédictibles par la seule connaissance des propriétés de ses constituants élémentaires.

REST et SOAP peuvent résoudre un grand nombre de problèmes et de défis web, et dans de nombreux cas, chacun d'eux peut être adapté au besoin des développeurs.

L'histoire secrète, c'est que les deux technologies peuvent être combinées. REST est très facile à comprendre et est très accessible, mais il est non standardisé et est plus considéré comme une approche architecturale. En comparaison, SOAP est un standard de l'industrie avec un protocole bien défini et un ensemble de règles bien établies à mettre en œuvre et il a été utilisé dans des systèmes à la fois grands et petits.

En conséquence, cela signifie que les besoins pour lesquels REST fonctionne vraiment bien sont les suivantes:

Les trois cas ci-dessus couvrent un grand nombre de besoins. Pourquoi donc devriez-vous même envisager SOAP ? Encore une fois, SOAP est assez mature, bien défini et vient avec une spécification complète. L'approche REST est simplement ça: une approche et il est grand ouvert pour le développement. Par conséquent, si vous êtes dans les cas suivants, SOAP est une excellente solution:

The simplest application that demonstrates the ports & adapters fortunately comes with the FIT documentation. It is a simple discount computing application:

In our adaptation, the amount will come from the user and the rate will come from a database, so there will be two ports. We implement them in stages:

Thanks to Gyan Sharma at IHC for providing the code for this example.

L'architecture tente d'avoir une vue long-terme, alors que les développements agiles se concentrent sur la valeur ajoutée immédiate. "Architecte" ne fait d'ailleurs pas partie des rôles Scrum...

Conforming to these simple rules is not hard, and will save you a lot of headaches going forward. By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies. When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss.

There are two "rules of three" in [software] reuse:

Vaugh Vernon, l'auteur d'Implementing Domain Driven Design, après une courte description de l'émergence de l'architecture comme le résultat naturel du DDD, a continué par une analyse de l'architecture en couches traditionnelle selon le livre du DDD d'Eric Evans avec une interface utilisateur au sommet et une couche d'infrastructure en bas. Un effet indésirable de cette architecture en couches est que l'implémentation, par exemple, des dépôts du domaine (repositories) dans la couche d'infrastructure cassent cette architecture vu que les dépôts dépendent du modèle du domaine. En les déplaçant en haut et en utilisant le principe d’inversion de dépendance pour les injecter, on évite de casser l'architecture et on la rend plus flexible en permettant l'injection de plusieurs implémentations.

De l'art de ré-inventer l'eau tiède...