Modelado de la Lógica de Negociosapit.wdfiles.com/local--files/start/03_apit_logica_de... ·...

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


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


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)


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.


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,


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.


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


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


• 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


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…


• Monolítica

• Cliente-Servidor

• Orientada a Plugins

• Social Architecture

• Enterprise

�BD Pesadas

�Transaccionales



�Transaccionales

�Interacción Humana

�Múltiples usuarios concurrentes


• Del punto de vista de la cátedra, hay dos

filosofías arquitectónicas extremas:


�Transaction Script

�Domain Model

Transaction Script

Orientadas a BD

Poca


Poca Lógica

WorkflowControlado

Transaction Script

� Relación Pantalla / Tabla

� Lógica de Negocio en Procedimientos

� ABMs

Orientadas a BD

Poca


Poca Lógica

WorkflowControlado

Transaction Script

� Aplicación como una serie de Transacciones

Orientadas a BD

Poca


� Funcionalidad Acotada

� Evolución costosa => Difícil de Mantener!

Poca Lógica

WorkflowControlado

Transaction Script

Orientadas a BD

Poca


� Cada transacción tendrá su propio

Transaction Script

� Input

� Proceso� Persistencia

Poca Lógica

WorkflowControlado

Transaction Script – Como Funciona

Service

Nombre

Apellido

Edad

UI


Quiero los Clientes Activos

Service

Service

Servicios

BD


Servicio

UI BDNombre

Apellido

Edad

Customer

AddressAddressId

Street


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


• 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


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


Lógica Compleja


Domain Model

Diseño OO

Lógica • Modelo Escalable


Lógica Compleja


• Modelo Escalable

• Reglas de Negocio bien Definidas en Objetos

Domain Model

Diseño OO

Lógica


Lógica Compleja


• Modelan la realidad => Reificación

• Minimiza la Brecha Semántica

Domain Model – Estilos de Modelado


Domain Model – Como Funciona


Domain Model vs Transaction Script

EsfuerzoTransaction Script


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


• 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:


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:


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.


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:


• 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


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:


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


Declarativa

Introspectiva / Reflexiva

• Todo mezclado en el mismo código

• Extremadamente difícil de mantener

Guardar()

No Separación


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


• 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


BD ORM

Container

Dominio

Objetos de Negocio

Validators

[Required]public voidEmail(stringemail)

• Ejemplo de una Annotation

Declarativa


{this.Email = email;

}

• Modifico el comportamiento de una aplicación.

• Aplicación orientada a Plugins

Introspectiva / Reflexiva


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


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


• 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


Server

Client



BD


BD



Presentation • Interacción entre el usuario y el SW


Data Source

Domain• Conceptos de Negocio

• Business Rules

• Comunicación con la BD



Nombre

Apellido

Edad BD


Nombre

Apellido

Edad BD



Application Services

Presentation• Define las tareas que puede hacer

el SW


Data Source

Domain

Application Servicesel SW

• Interactúa con otros Sistemas

• Coordina y delega las tareas



BD

Nombre

Apellido

Edad


BDApp

Hexagonal Architecture

• También conocido como Ports & Adapters


Domain

App

Separated Interfaces

Domain DB


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


Lógica a Alto Nivel

Modelo Visual

• El motor administra el estado, persistencia y

correlación de los mensajes

• Fácil comunicación

Workflow - Tipos

State Machine


Sequential

Rule Based

• 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


• Las tareas del WF pueden ejecutarse de manera

autónoma con poco control externo.

Sequential


Bibliografía: Martin Fowler

� Analysis Patterns: Reusable Object Models by Martin Fowler

� Domain-Driven Design

by Eric Evans


� Patterns of Enterprise Application Architecture.by Martin Fowler

Modelado de la Lógica de Negociosapit.wdfiles.com/local--files/start/03_apit_logica_de... ·...

Documents

Transcript of Modelado de la Lógica de Negociosapit.wdfiles.com/local--files/start/03_apit_logica_de... ·...