Strategy: An Architectural Reference Model for the Enterprise Applications – A Case Study

El ponent d'aquesta sessió ha estat Mark Collins-Cope Technical Director de l'empresa ratio group.

Bàsicament s'ha exposat una arquitectura SOA que no té cap novetat ni és cap birgueria, bàsicament és un popurri de coses que tothom coneix. L'interessant ha estat l'enfoc pràctic de l'exposició ja que en cada aspecte de l'arquitectura ha posat casos de com portar-ho a terme.Aquesta arquitectura és utilitzada en projectes reals en l'empresa on l'home treballa i és fruït de l'evolució durant 20 anys de la seva carrera professional. Els objectius amb els quals s'ha concebut són els següents:

• Factoring: significa reduir el número de línies a picar en nous projectes(és a dir reutilització de codi), també aconsella utilitzar refactoring per millorar i evolucionar el codi existent. L'avantatge d'això és la reducció de bugs en nous productes ja que aquests es desenvoluparan sobre mitjançant codi,llibreries, etc. ja testejades.
  
• Intelligibility: significa organitzar el codi d'una manera racional i clara de cara tan a facilitar el manteniment i evolució del producte, com a reduïr el cost d’introduir gent nova.
  Separation: la clàssica separació de conceptes(UI, lògica i infraestructura). Els beneficis d'això ja són coneguts per tothom.
  
• Stability: l'arquitectura defineix una sèrie de capes, l'objectiu és que les capes inferiors(més genèriques, reutilitzables) siguin el màxim d'estables possible per donar robustesa a cada nou producte.
  
• Testability: implementar un projecte pensant des del principi en el test, utilitzar unit testing.

Un cop exposats els objectius l'home ha mostrat les capes de l'arquitectura i les regles que cal seguir per utilitzar-la amb resultats satisfactoris.

Capes

• Interface: dins d'aquesta capa hi han d'anar tots els components que fan d'interfície del sistema cap a actors externs, ja siguin interfícies gràfiques com interfícies amb altres sistemes(Host, SAP, etc.)
  
• Application: En aquesta capa és on hi ha els serveis que implementen la lògica de negoci.
  
• Domain: capa que conté elements genèrics com per exemple un component de gestió de comptes, han de ser genèrics pq l'objectiu és reaprofitar aquests elements en altres projectes. De cara a adaptar cada component a cada nou projecte el ponent recomana definir outerfaces que siguin implementades a la capa d'aplicació.
  
• Infraestructure: capa on es troben el components genèrics a nivell tecnològic com poden ser llibreries de persistència o classes d'accés a dades.
  
• Platform: aquí és on entren els components externs com per exemple windows forms, jdbc, etc.

Regles:

• les dependències sempre han de ser d'un component d'una capa superior a un component d'una capa inferior
  
• sempre s'ha d'intentar moure els components a capes inferior ja que així probablement seran més genèrics i per tant reaprofitables en projectes posteriors
  
• mai un component ha de contenir elements de més d'una capa
  

Segons el propi ponent la eina bàsica per portar a terme aquesta arquitectura és una pissarra on es dibuixen 5 línies horitzontals que defineixen les capes, allà es dibuixen els components a desenvolupar o reutilitzar i a saco a programar ;-)

En resum i com ja he dit l'arquitectura no planteja cap novetat, però ha estat interessant com s'ha exemplificat la seva aplicació