Arquitectura de Proyectos de IT
Modelado de la Lógica de Negocios
© 2005
David CanterosJuan Manuel Arias
Introducción
Es el conjunto de operaciones que producen la información que requiere el usuario.
Representación en la arquitectura
2Arquitectura de Proyectos de IT
Representación en la arquitectura
Representación del dominio
Concepto de operaciones
Interactúa con el resto de las capas de una arquitectura, consumiendo o proveyendo información.
Comúnmente es modelada por medio de abstracciones (conceptos que dominan el problema) prescribiendo la interacción entre ellos para
Introducción
3Arquitectura de Proyectos de IT
dominan el problema) prescribiendo la interacción entre ellos para lograr la operación deseada.
Estas operaciones son representadas por decisiones lógicas, evaluaciones y cálculos (algoritmos)
Introducción - Interacción / Relación
Seguridad Transacciones
4Arquitectura de Proyectos de IT
Lógica de negocioAuditoría
Logging
Testing
Persistencia
¿Que rol juegan los lenguajes?
Los lenguajes “imponen” restricciones en cuanto a decisiones de diseño en nuestra lógica de negocios.
Ciertos lenguajes ofrecen características que pueden mejorar la expresividad. (Static vs Dinamic)
5Arquitectura de Proyectos de IT
Ruby: Modules, blocks, Mixin, Metaprograming, Duck typing, etc.
Vs
Java: Clases abstractas, Interfaces, Generics, Enum
Cómo arquitectos debemos tener en cuenta estas características y seleccionar la tecnología que mas se adapte al problema.
¿Que rol juegan los lenguajes?
Readability: La legibilidad debe ser considerada en el contexto del problema. Si la lógica de negocios es descripta en un lenguage que no fue diseñado para este propósito podría ser poco natural, complicado y muy difícil de leer.
Este criterio afecta a la fiabilidad del sistema, desde el punto de vista de la mantenibilidad. Lógica de negocio difíciles de leer,
7Arquitectura de Proyectos de IT
vista de la mantenibilidad. Lógica de negocio difíciles de leer, resultan difíciles de escribir y modificar.
Writability: Medida que nos permite determinar o conocer sobre que tan fácil es crear un programa para un contexto determinado. La mayoría de las características que afectan a la readability afectan a la writability.
¿Que rol juegan los lenguajes?
Reliability: Se puede decir que nuestra lógica de negocios está diseñada de forma confiable si esta cumple con todas las especificaciones que nombramos. (Readability, Writability, etc)
Productivity: Criterio que apunta a que tan flexible es el lenguage de programación, tanto para su entendimiento como
8Arquitectura de Proyectos de IT
Productivity: Criterio que apunta a que tan flexible es el lenguage de programación, tanto para su entendimiento como para su uso. Algunos puntos para determinar la productividad son:
Simple e intuitivo.Fácil de aprender y aplicar.Eficiente.Assets y estándares.
Lógica de negocio y Arquitectura
Es deseable que los componentes que ejecutan la lógica de negocio, no contengan otras funcionalidades.
Deben ser agnósticos sobre aspectos arquitecturales:
• Presentación
• Persistencia
9Arquitectura de Proyectos de IT
• Persistencia
• Etc.
Tres factores muy importantes a considerar
• Separation of Concerns.
• Information Hidding.
• Orthogonality.
Lógica de negocio y Arquitectura
Simplicidad: Logrando que los componentes de negocio sean simples, y sólo contengan operaciones relacionada con esto.
Expresividad: Fácil de leer, de entender y por ende de modificar. Afecta a la extensibilidad.
Modificabilidad: Sin expresividad sería difícil la modificabilidad, sin
10Arquitectura de Proyectos de IT
Modificabilidad: Sin expresividad sería difícil la modificabilidad, sin modificablidad no tendríamos fiablidad integral (Reliability)
Alta cohesión: Queremos que los componentes contengan las operaciones que realmente les competen.
Reusabilidad: Queremos que los componentes se puedan usar con distintas interfaces y por lo tanto no deben depender de ninguna.
Independencia: No queremos componentes atados a una solución de algún fabricante específico.
• Enterprise
• Monolítica
Modelado de lógica de negocios
Varía según el tipo de Arquitectura…
11Arquitectura de Proyectos de IT
• Monolítica
• Cliente-Servidor
• Orientada a Plugins
• Social Architecture
• Enterprise
�BD Pesadas
�Transaccionales
Modelado de lógica de negocios
12Arquitectura de Proyectos de IT
�Transaccionales
�Interacción Humana
�Múltiples usuarios concurrentes
Modelado de lógica de negocios
• Del punto de vista de la cátedra, hay dos
filosofías arquitectónicas extremas:
13Arquitectura de Proyectos de IT
�Transaction Script
�Domain Model
Transaction Script
Orientadas a BD
Poca
14Arquitectura de Proyectos de IT
Poca Lógica
WorkflowControlado
Transaction Script
� Relación Pantalla / Tabla
� Lógica de Negocio en Procedimientos
� ABMs
Orientadas a BD
Poca
15Arquitectura de Proyectos de IT
Poca Lógica
WorkflowControlado
Transaction Script
� Aplicación como una serie de Transacciones
Orientadas a BD
Poca
16Arquitectura de Proyectos de IT
� Funcionalidad Acotada
� Evolución costosa => Difícil de Mantener!
Poca Lógica
WorkflowControlado
Transaction Script
Orientadas a BD
Poca
17Arquitectura de Proyectos de IT
� Cada transacción tendrá su propio
Transaction Script
� Input
� Proceso� Persistencia
Poca Lógica
WorkflowControlado
Transaction Script – Como Funciona
Service
Nombre
Apellido
Edad
UI
18Arquitectura de Proyectos de IT
Quiero los Clientes Activos
Service
Service
Servicios
BD
Transaction Script – Como Funciona
Servicio
UI BDNombre
Apellido
Edad
Customer
AddressAddressId
Street
19Arquitectura de Proyectos de IT
CustomerId
Name
LastName
SalesmanId
AddressId
SalesmanSalesmanId
PersonId
AddressId
Transaction Script – A tener en cuenta
• Aplicaciones con poca lógica
• Es muy frecuente que el comportamiento común
se vea duplicado
21Arquitectura de Proyectos de IT
• Si la lógica se vuelve más compleja, entonces
progresivamente será más difícil de mantener
• No es OO
Domain Model
Diseño OO
Lógica
22Arquitectura de Proyectos de IT
Lógica Compleja
Representan la realidad
Domain Model
Diseño OO
Lógica
• Lógica de Negocios modelada con un diseño OO
• Unit Test de mi modelo
• Los Objetos tienen Comportamiento
23Arquitectura de Proyectos de IT
Lógica Compleja
Representan la realidad
Domain Model
Diseño OO
Lógica • Modelo Escalable
24Arquitectura de Proyectos de IT
Lógica Compleja
Representan la realidad
• Modelo Escalable
• Reglas de Negocio bien Definidas en Objetos
Domain Model
Diseño OO
Lógica
25Arquitectura de Proyectos de IT
Lógica Compleja
Representan la realidad
• Modelan la realidad => Reificación
• Minimiza la Brecha Semántica
Domain Model vs Transaction Script
EsfuerzoTransaction Script
30Arquitectura de Proyectos de IT
Complejidad de la Lógica de Dominio
Domain Model
Domain Model – A tener en cuenta
• Contribuye al conocimiento del negocio
• Escalable en cuanto a la complejidad del negocio
• Incremento en la carga de trabajo
31Arquitectura de Proyectos de IT
• Incremento en la carga de trabajo
• Requiere un diseño más esmerado
• La arquitectura debe acomodarse al negocio
• El dominio debe encontrarse lo más aislado posible
Separation of Concerns
Concerns: Es una pieza de software (componente, clase, etc) que debe ser implementada en el sistema.
Cross-cutting concern: Funcionalidad que afecta a toda nuestra arquitectura. No se trata de una responsabilidad específica de un componente. Debe ejecutarse para todo un conjunto de componentes.
Conceptos básicos:
32Arquitectura de Proyectos de IT
ejecutarse para todo un conjunto de componentes.
El paradigma orientado a objeto provee algunos mecanismos para alcanzar cierto grado de modularización: soporte por abstracciones, tipo de datos, separación de la interfaz de su implementación, etc. Sin embargo el nivel de abstracción que podemos alcanzar con estos mecanismos esta acotado a una única dimensión.
A medida que se incrementa la complejidad en el desarrollo de software estos tienen que enfrentarse con el manejo e incorporación de diferentes concerns:
Separation of ConcernsConceptos básicos:
33Arquitectura de Proyectos de IT
General: sincronización, persistencia, logging, seguridad, error handling.
Específicos: concurrencia, fault recovery, event scheduling, etc.
Estos concerns comúnmente se incorporara para alcanzar ciertos requerimientos del sistema (persistencia, seguridad) o para mejorar ciertos atributos de calidad (fault tolerance, concurrencia, etc).
Pero surgen varios problemas a la hora de la incorporación de estos concerns que afectan a la mantenibilidad, confiablidad y otros atributos de calidad del sistema. Dos de los problemas más conocidos son los siguientes: Code tangling y code scattering
Separation of ConcernsAlgunos problemas que intenta resolver:
Code TanglingEstos síntomas aparecen cuando un módulo contiene código que implementa diferentes características del sistema. Lo deseable sería que cada una de ellas estuviera implementada en su módulo correspondiente.
34Arquitectura de Proyectos de IT
Code ScatteringEstos síntomas son opuestos al caso anterior, la implementación de una características del sistema la encontramos dispersa entre varios módulos. La característica está repetida en varios módulos.
Separation of ConcernsAlgunos problemas que intenta resolver:
Rompe los principios:
35Arquitectura de Proyectos de IT
• Single Responsability Principle• Open/Close Principle
Separation of Concerns
La disciplina de SoC basa su objetivo en reducir la complejidad y mejorar la evolución del software,
proveyéndonos de técnicas
36Arquitectura de Proyectos de IT
mejorar la evolución del software, proveyéndonos de técnicas enfocadas en la correcta organización de concerns (generales o específicos).
Separation of Concerns (Cont.)
ReflectionEs una técnica que nos permite modificar la estructura de un componente en tiempo de
compilación o en tiempo de ejecución. • Introspección• Intersección
Metaprogramming
Algunas técnicas:
37Arquitectura de Proyectos de IT
MetaprogrammingCapacidad que tiene un programa de modificar o crear programas.
Aspect-Oriented Programming (AOP)Es un paradigma que complementa al paradigma de objetos, resolviendo el tratamiento de los
cross-cutting concerns. Permite isolar de nuestra lógica de negocios (u otros componentes) las modulos secundarios o de infraestructura (Persistencia, logging, etc).
• Join point: posición bien definida en el flujo del programa.• Pointcuts: consiste en la declaración de un conjunto de join points• Advice: Implementación del aspecto.
Otras técnicas: Composition Filter, Subject Oriented Programming, Generative Programming, Multi-dimmensional Separation of Concerns.
Mecanismos de separación de la lógica
No Separación
Programática
38Arquitectura de Proyectos de IT
Declarativa
Introspectiva / Reflexiva
• Todo mezclado en el mismo código
• Extremadamente difícil de mantener
Guardar()
No Separación
39Arquitectura de Proyectos de IT
Guardar()
{
// Manejo el evento de guardar
// Abro una transacción
// Verifico reglas de negocio
// Logueo la transacción
// Guardo
// Cierro la transacción
}
• Separación de responsabilidades mediante distintos
objetos que se envían mensajes entre sí
Programática
40Arquitectura de Proyectos de IT
• Separo la lógica de negocio de aspectos intrusivos
• Parametrizo fuera del código los componentes
arquitecturales vinculados a la lógica de Negocio
Declarativa
41Arquitectura de Proyectos de IT
BD ORM
Container
Dominio
Objetos de Negocio
Validators
[Required]public voidEmail(stringemail)
• Ejemplo de una Annotation
Declarativa
42Arquitectura de Proyectos de IT
{this.Email = email;
}
• Modifico el comportamiento de una aplicación.
• Aplicación orientada a Plugins
Introspectiva / Reflexiva
43Arquitectura de Proyectos de IT
Dominio
PluginPluginPlugin
Arquitectura en n Capas
• Divide un sistema complejo
• Cada capa usa los servicios brindados por la capa
inferior y expone servicios a la capa superior
Application
44Arquitectura de Proyectos de IT
Physical
Data Link
Network
Transport
Session
Presentation
Application
Arquitectura en n Capas (cont.)
• Cambios en forma de cascada
• Capas extra pueden
• Abstracción entre capas
• Minimiza las dependencias
• Buenas para estandarizar
45Arquitectura de Proyectos de IT
• Capas extra pueden impactar en la performance
• Buenas para estandarizar
• Se pueden reemplazar “fácilmente”…
Arquitectura en n Capas - Evolución
�Arquitectura de 2 Capas
Client
46Arquitectura de Proyectos de IT
Server
Client
Arquitectura en n Capas - Evolución
�Arquitectura de 2 Capas
BD
47Arquitectura de Proyectos de IT
BD
Arquitectura en n Capas - Evolución
�Arquitectura de 3 Capas
Presentation • Interacción entre el usuario y el SW
48Arquitectura de Proyectos de IT
Data Source
Domain• Conceptos de Negocio
• Business Rules
• Comunicación con la BD
Arquitectura en n Capas - Evolución
�Arquitectura de 3 Capas
Nombre
Apellido
Edad BD
49Arquitectura de Proyectos de IT
Nombre
Apellido
Edad BD
Arquitectura en n Capas - Evolución
�Arquitectura de 4 Capas
Application Services
Presentation• Define las tareas que puede hacer
el SW
50Arquitectura de Proyectos de IT
Data Source
Domain
Application Servicesel SW
• Interactúa con otros Sistemas
• Coordina y delega las tareas
Arquitectura en n Capas - Evolución
�Arquitectura de 4 Capas
BD
Nombre
Apellido
Edad
51Arquitectura de Proyectos de IT
BDApp
Hexagonal Architecture
• También conocido como Ports & Adapters
52Arquitectura de Proyectos de IT
Domain
App
Separated Interfaces
Domain DB
53Arquitectura de Proyectos de IT
No se puede mostrar la imagen. Puede que su equipo no tenga suficiente memoria para abrir la imagen o que ésta esté dañada. Reinicie el equipo y, a continuación, abra el archivo de nuevo. Si sigue apareciendo la x roja, puede que tenga que borrar la imagen e insertarla de nuevo.
Mock DB
Workflow
• El proceso de Negocio está diseñadoFlujo
Orquestado
54Arquitectura de Proyectos de IT
Lógica a Alto Nivel
Modelo Visual
• El motor administra el estado, persistencia y
correlación de los mensajes
• Fácil comunicación
• Las tareas del WF dependen de un control externo que
guiará la ejecución, como por ejemplo la interacción
con un usuario
State Machine
56Arquitectura de Proyectos de IT
• Las tareas del WF pueden ejecutarse de manera
autónoma con poco control externo.
Sequential
57Arquitectura de Proyectos de IT