Get Started for FREE
Sign up with Facebook Sign up with X
I don't have a Facebook or a X account
 Your new post is loading...
Your new post is loading...
Scoop.it!
L'architecture est une affaire d'intention, nous en avons fait une question de frameworks et de détails. C'est le constat qu'a fait Robert C. Martin, "Uncle Bob", au début de l'année au DDD Exchange Day de Londres. 
No comment yet.
Sign up to comment
Scoop.it!
The New 3-Tier Architecture:HTML5, Proxies, and APIs by Brian Mulloy and Kevin Swiber (Apigee)
Companion video here : http://goo.gl/YBECx
Via Nicolas Weil
Dolly Bhasin 's curator insight,
December 30, 2012 11:20 PM
Great work, just what I was looking for! Thanks for sharing! |
Scoop.it!
When building a service-oriented architecture, it is important to identify which components will be responsible for which information. For a particular “truth”, you must ensure that your system defines a single component that is responsible for it.
Scoop.it!
Planning ahead to ensure your software can evolve along with the rest of the tech world is even more essential when you’re developing an API. If you don’thave a plan for versioning your API, you could find yourself up a creek without a paddle. And it’ll take a lot of time, cough, money, to get the heck out of that creek. In this post, we’ll consider some best practices for versioning an API, no matter what, and then go on to discuss three possible ways to architect your API, depending on your project and situation. Via Nicolas Weil
|
Robert renvoie au modèle architectural décrit dans le livre Growing Object-Oriented Software Guided by Tests, (similaire à l'Architecture Hexagonale), qui décrit une architecture divisée en trois zones dont les dépendances ne vont que dans un sens, des plus volatiles vers les plus stables.
Un Modèle de Domaine contenant les règles du coeur de métier, la partie la plus stable et importante qui ne dépend de rien d'autreDes Services Applicatifs pour les Cas d'Utilisation du système, qui utilisent et dépendent du Modèle de DomaineDes détails externes, une base de données, des interfaces utilisateurs, un réseau, etc... qui sont moins pertinents par raport au Modèle de Domaine. C'est la partie la plus volatile qui dépend des deux autres.Robert remarque que ce modèle échoue à décrire ce qu'il considère comme un point clé : l'architecture est liée à l'Intention, ce que FAIT l'application. Il pense qu'on se focalise trop sur les détails et les frameworks jusqu'à en faire le centre de nos systèmes.
Pour résoudre ce problème Robert revient au livre d'Ivar Jacobson, "Le génie logiciel orienté objet, une approche fondée sur les cas d'utilisation", paru en 1992, dans lequel Ivar définit un mécanisme pour produire une architecure applicative en s'appuyant sur de petits cas d'utilisations peu détaillés.