Objectiu formatiu

Establir vocabulari comú per modularitzar les aplicacions

Revisar les forces de disseny en joc quan decidim on posar les fronteres entre components

Encetar un debat estratègic pels diferents escenaris que tenim (ERP, WebApps…)

Context

Components:
Com distribuim responsabilitats?
A on establim les fronteres?

Perseguim baix acoblament i alta cohesió

La arquitectura multicapa, estableix punts possibles de tall per la componentització.

Independents del domini!

Bon punt de partida, aprofitem-los

Les capes

Son capes irreals

Irreals com el model OSI de xarxes:

No cal correspondència Component - Capa

Pero les funcions han de ser-hi!

Serveixen per pensar/comunicar
on posar fronteres i responsabilitats

Presentació

Aplicació

Negoci/Domini

Entitats

Persistència

Divisió horitzontal

Capes d’aplicació seria la divisió vertical

Horitzontal: Per temàtiques o funcionalitats

De la conjunció surten els components del sistema.

Decissions

què repliquem o no

què centralitzem o distribuim

què diversifiquem o uniformem

quines fronteres (API’s) definim

duplicació vs replicació

Aplicació i negoci

La de negoci és la lògica compartida per les aplicacions.

Si tenim diverses aplicacions,
no dupliquem la lògica de negoci a cadascuna.

Compartim un component que la contingui.

Llibreria, API, servei…

Mola exposar accions de negoci
(tambè s’en diu la capa de serveis o operacions)

Entitats i negoci

CRUD/ORM: representació d’entitat

Entitat no aporten per se lògica de negoci

ORM’s augmentats amb operacions de negoci?
Es bo per construir el nivell de Negoci.

El problema es quan oferim l’ORM a Aplicació, permetent-li saltarse restriccións de Negoci.

Aplicació i presentació

Client-servidor:
Al servidor només estava Persistencia.

LAMP clàssic:
Presentació era l’HTML generat,
l’applicació estava al servidor.

Single Page App:
Presentació i aplicació al navegador.

Situació

Aplicacións: ERPClient, molts scripts, OV, Webforms

Les aplicacions accedeixen a diferents nivells d’abstracció.

Hi ha lógica del negoci fora.

S’ofereixen API’s a nivell de vista (wizards) que haurien de ser de negoci

S’ofereix API a nivell entitats (orm)

Abstracció nivell d’entitats als usuaris!

Problemes

Acoblament a l’estructura de la base de dades

Rígidesa en el disseny

Ens saltem la lógica de negoci

Repliquem la lógica de negoci
(i mantenim les répliques desigualment)

Acoblament amb els camps i disseny dels wizards

Ús tipus CRUD

No hi ha abstracció de negoci

Acoblament a la representació

Genera rigidesa

Abstreure ops i moure-les a l’ERP

Bad smell de que hi ha lógica de negoci fora.

Logica de negoci fora

Ficar la lògica de negoci dintre de l’ERP

Definir interfície que segueixi aquesta lògica de negoci

Operacions de negoci

API’s tipus wizard

Erpppek fa servir wizards com a API

Wrappejar la crida al wizard

Moure-la a l’ERP, com a op de domini

Extreure la lògica de negoci com a API

Cridar aquesta API des del wizard

Cridar aquesta API des de l’erppeek

Procediment

Abstreure ops a l’erppeek
cobertes amb tests!
si no tenim, b2b i/o funcionals d’allò que ho crida
unitaris després de la funció extreta

Replicar-les a l’ERP com a API accessible
Intentar replicar els casos unitaris a destral
Delegar mantenint testos interns i externs

API’s amb diccionaris

Pot semblar còmode
‘flexibilitza’ els arguments que es passen

Complica l’ús:
Signatura ja no es documentació
Errors tipogràfics silenciosos

Fer servir paràmetres explicits
Problema: XMLRPC no soporta keywords

Si els paràmetres depenen de la casuística,
potser convé oferir diferents punts d’entrada.