Modelando la Lógica de Negocio - APIT-UTNapit.wdfiles.com/local--files/start/03_apit_logica_de_negocio_2011... · Buenas Prácticas > Aislar el modelo Arquitectura típica en 4 capas

Modelando la Lógica de Negocio

Ing. Juan M. Arias2011

Arquitectura de Proyectos ITUTN - FRBA

Modelando la Lógica de Negocio

Domain Model

DDD

Layers

Hexagonal Arch.

SoC

DSL

Wednesday, May 4, 2011

Arquitectura de Proyectos ITModelando la Lógica de Negocio

Agenda> Introducción

> Domain Model> Domain Driven Design

> Capas> Alternativas a las Capas

> Mecanismos de Separación> DSL

> BPM



Introducción


Arquitectura de Proyectos ITIntroducción

Algunos tipos de Arquitectura

> Sociales

> Móviles

> Games

> Empresariales

4Wednesday, May 4, 2011

Arquitectura de Proyectos ITIntroducción

¿Qué es la Lógica de Negocio?– Conceptos de negocio.

– Conjunto de procesos.

– Contiene información de los estados de los procesos de negocio.

Es el Corazón de Nuestro Sistema



Domain Model


Arquitectura de Proyectos ITDomain Model

¿Qué es un Modelo?– Una visión simplificada de algo complejo utilizado en el

análisis y resolución de problemas.

– Debe tener un propósito.



¿Qué es Domain Model?– Es un modelo que representa un Dominio de Negocio.

– Debe expresar el Dominio y no los detalles técnicos.

– No es un diagrama UML o un esquema de BD.

– Debe ser relevante tanto para los expertos de dominio como para el equipo de desarrollo.



ComponentesAb

stra

cció

n

Tecnología Negocio

Diagrama de Clases y Secuencia

Unit Test

Código OO

Esquema de Base de Datos

Diagrama de Capas

Diagrama de Deploy

BPM & Workflow

Data examples

Story test

Prototypes

DSL

Obtenido de Architecture

Journal Magazine



Diseño - Aislando el Modelo– Separar el dominio de los demás aspectos

– Evitar el acoplamiento – Pensar en el cambio, no implica que todo va cambiar

– Las capas no siempre son la solución

El Dominio es el Core de nuestra aplicación



Principios claves de Diseño

Single Responsability Principle

Open Close PrincipleLiskov Substitution Principle

Interface Segregation PrincipleDependency Inversion Principle

> SOLID



Principios claves de Diseño

> Diseño altamente Cohesivo.

> Código transversal abstraído de la lógica de la aplicación.

> Separation of Concerns

> DRY (Donʼt Repeat Yourself)

> YAGNI (You Ainʼt Gonna Need It)



DDDDomain Driven Design


Arquitectura de Proyectos ITDDD - Domain Driven Design

¿Qué es DDD?– ¿Podemos construir software complejo sin conocer el dominio?

– ¿Quién conoce el negocio? ¿El Arquitecto? ¿El Desarrollador?

– Necesitamos crear una Abstracción del Dominio.

– Modelo OO que refleja el conocimiento de un Dominio.



El Problema de la ComunicaciónQuiero que se puedan cambiar las reglas de las políFcas para disFntos clientes

Podemos usar un Strategy Podemos

usar IoC

¿Que es IoC?

¿Nos entendemos realmente?



Lenguaje Ubicuo

Traducir

Domain Expert

Technical Expert

Refinar

Acordar

Jerga

Jerga



Lenguaje Ubicuo

Domain Expert

Technical Expert

Lenguaje Ubicuo

Bounded Context

Bounded Context

Bounded Context



Lenguaje Ubicuo– Facilitamos la transferencia de conocimiento.

– Los desarrolladores tienen un buen conocimiento del dominio.

– Requiere tiempo y esfuerzo

Arquitecto y Experto más Felices



TDD

Red Green Refactor

Buenas Prácticas

– Desarrollo de UT que sirven como especificación.

– Pensar en la interface antes de la implementación.

– Código dirigido por los Test

> TDD



Buenas Prácticas> Aislar el modelo Arquitectura típica en 4 capas

User Interface

Applica:on

Domain

Infraestructure



Layers


Arquitectura de Proyectos ITLayers - Capas

Capas– Agrupaciones horizontales lógicas de componentes de

Software.

– Ayudan a diferenciar los distintos tipos de tareas.

– Maximiza la reutilización.

– Ayuda a aplicar el principio de SoC (Separation of Concerns o Separación de Responsabilidades).

No confundir Layers con Tiers



Capa de Persistencia

Persistencia

– Centraliza el acceso a la/s fuente/s de datos/s.

– Desacopla la tecnología utilizada.

– Se utilizan DAOs y/o Repositorios.

– Puede implementarse con un ORM (Hibernate, Entity Framework, etc.).

– Algunos patrones:Active RecordData MapperTable Module



Capa de Dominio

Dominio

– Implementa la funcionalidad principal de nuestro Sistema.

– Aislado de la Infraestructura.

– Cuenta con Entidades

– Anemic Model: Cuando nuestras entidades no tienen lógica propia.

– Contrato de Interfaces.

– Las operaciones surgen del modelo ubicuo



Capa de Dominio

Dominio

– Identificar bien las responsabilidades.

– Alta cohesión.

– No mezclar componentes.

– Reutilizar lógica común.

– Hacer uso de abstracciones.

> Algunas consideraciones



Capa de Aplicación

Aplicación

– Coordina actividades de la Aplicación.

– No incluye lógica de Negocio.

– Coordina servicios de la capa de nivel inferior.

– Es como una fachada (Façade).

– Puede incluir workflows.

– Puede incluir conversores a DTO en casode contar con dichos objetos.



Capa de Servicios

Servicios

– Se trata de Servicios Distribuidos.

– Primero necesito tener definido el contrato.

– Una vez más, los servicios son una fachada de nuestra lógica.

– Expone servicios a la capa de presentación o a otros servicios.

– Intercambian estructuras de datos serializadas,DTOs o valores escalares.

– Uso de REST o SOAP



Capa de Servicios

ServiciosServicio

Aplicación Aplicación Aplicación



Capa de Presentación

Presentación

– Describe la Interfaz de Usuario.

– No olvidar que es lo que el usuario ve.

– Evitar acoplamiento entre componentes.

– No olvidarse de los Unit Test.

– Algunos Patrones:MVCMVPMVVM



Capa de Infraestructura Transversal

Inf. Transversal

– Aspectos Horizontales

– Impactan en toda la aplicación.

– Busca componentes comunes para favorece la reutilización

– Se utilizan técnicas como DI y AOP.

– Aspectos transversales:SeguridadCacheLoggingValidaciones de Input



Capa de Infraestructura Transversal> Radiografía de una aplicación no modularizada

> Radiografía de una aplicación modularizada



Persistence

Domain

Applica:on

Service

Presenta:on

Database

Transversal



Persistence

Domain

Applica:on

Service

Presenta:on

Database

Transversal

Caching

Security

Logging

IoC Repository

Repository Contracts

Applica)on Services

DTOs

Model

Controller

View

Web

En))esCore

Domain Services

Core



Persistence

Domain

Applica:on

Service

Presenta:on

Database

Transversal

Caching

Security

Logging

IoC Repository

Repository Contracts

Applica)on Services

DTOs

Model

Controller

View

Web

En))esCore

Domain Services

Core



Persistence

Domain

Applica:on

Service

Presenta:on

Database

Transversal

Caching

Security

Logging

IoC Repository

Applica)on Services

DTOs

Model

Controller

View

Web

En))esCore

Domain Services

Core

Aunque a veces encontramos esto…!!



Algunas Consideraciones> Suelen existir un acoplamiento al no respetar el Principio

de Inversión de Dependencia.> Cambios en cascada.

> Puede haber problemas de Performance.> Demasiado complejo para:

– Aplicaciones orientada a datos.– Aplicaciones pequeñas

– Pocas reglas de negocio

Seamos Agiles!



AlternaFvas a las Capas


Arquitectura de Proyectos ITAlternativa a las Capas

RAD - Rappid Application Development> Aplicaciones pequeñas con pocos cambios.

> Orientadas a los datos> Algunos ejemplos:

– Dynamic Data .NET– Ruby on Rails

– MVC Scaffolding– Lightswitch



Hexagonal Architecture– Port & Adapters– Contratos para la integración con el Dominio– El Dominio es agnóstico a las tecnologías– Separated Interfaces Pattern



Domain

Mock DB

UI

Unit Test

DB

App

Hexagonal Architecture

Aislamiento por medio de Interfaces



Hexagonal Architecture> Metodología

Aplicación

Mock DB DB Access

Tests User UI

1 2 3 4



Hexagonal Architecture

Domain

DB

Mock DB



Transaction Script> Orientada a Datos.

– Relación pantalla / tabla– Lógica en Procedimientos

> Poca Lógica– Funcionalidad acotada

– Evolución costosa y difícil de mantener> Workflow controlado

– Cada transacción tiene su Transaction Script



Transaction Script

User Interface

Services

Infraestructure

> Diseño



Transaction Script

Servicio

UI DBNombre

Apellido

Edad



Transaction Script



Transaction Script> Algunas consideraciones

– No existe un modelo de la lógica.

– Suele existir código duplicado.

– Si la lógica se vuelve más compleja, progresivamente será más difícil de mantener.

– No utiliza el Paradigma Orientado a Objetos.



Transaction Script> Comparación con un modelo en capas

Esfu

erzo

Complejidad de la lógica de Dominio

TransactionScript

Domain

Model



Separación de la LógicaMecanismos de


Arquitectura de Proyectos ITMecanismos de Separación de la Lógica

¿Qué pasa cuando no separamos la lógica?

Guardar(){ // Manejo el evento de guardar // Abro una transacción // Verifico reglas de negocio // Logueo la transacción // Guardo // Cierro la transacción}

Guardar

– Código Spaghetti.

– Extremadamente difícil de mantener.



Mecanismos de Separación

> Separación Programática

> Separación Declarativa

> Separación Introspectiva / Reflexiva



Separación Programática– Separación de responsabilidades mediante distintos

objetos que se envían mensajes entre sí.

Objeto de

Negocio

DAO



Separación Declarativa– Separa la lógica de negocio de aspectos intrusivos.

– Parametriza fuera del código los componentes arquitecturales.

– Me concentro en el qué y no en el cómo.



Separación Declarativa> XAML - eXtensible Application Markup Language

– Lenguaje declarativo basado en XML para interfaces

– Soporte clases y métodos– Separo la definición de la interfaz de su lógica de

comportamiento

Guardar <Button Width="102" Height="31" Click=“OnClick” />



Separación Declarativa> Metadata

[Required]public void Email(string email){ this.Email = email;}

Annotat

ion



Separación Declarativa> Beneficios de utilizar Aspectos

Sin Aspectos

Con Aspectos



Separación Declarativa> AOP (Aspectos)

– Trata de resolver el problema de Cross-Custting Concerns.

– Separo la lógica de negocio componentes de infraestructura.

– Parametrizo fuera del código los componentes arquitecturales.



Separación Declarativa> Aspectos típicos de una aplicación

– Seguridad

– Cache– Gestión de Configuración

– Gestión de Excepciones– Logging

– Validaciones de datos de entrada



Separación Declarativa> Ejemplo de un aspecto de Logging

public ActionResult Customers(){ var logger = new Logger(); logger.Log(string.Format(“Se accedió al método ‘Customers' del controlador ‘Home’”)); // Get Customers return View();}

Sin Aspectos

View Controller



Separación Declarativa> Ejemplo de un aspecto Logging

View Controller

[HandleLogging]public ActionResult Customers(){ // Get Customers return View();}

Con Aspectos

Ejemplo uFlizando AcFon Filters de ASP MVC 3



Separación Declarativa> Ejemplo de un aspecto Logging

public class HandleLoggingAttribute : ActionFilterAttribute { public override void OnActionExecuted(ActionExecutedContext context) { base.OnActionExecuted(context); Log(context); }

private void Log(ActionExecutedContext context) { var logger = new Logger();

logger.Log(string.Format("Se accedió al método {0} del controlador {1}", context.ActionDescriptor.ActionName, context.ActionDescriptor.ControllerDescriptor.ControllerName)); } }

El Aspecto



Separación Introspectiva / Reflexiva– Puedo manipular la lógica utilizando Reflection.

– Modifica el comportamiento de mi aplicación.– Me permite extender mi aplicación.

Dominionuevo Comportamiento



DSLDomain Specific Language


Arquitectura de Proyectos ITDSL – Domain Specific Language

¿DSL… y eso con que se come?– El diseño de una Aplicación mapea un problema de dominio

con su implementación.– Para que ese mapeo sea posible, necesitamos un

vocabulario común que ambos dominios compartan.

MAP

Problem Domain

Security

Stock

Bonds

Solu3on Domain

Classes

Objects

Methods



¿Qué es un DSL?– Es un lenguaje de programación dedicado a resolver un

problema particular.

– Es un lenguaje específico a mi dominio en contraposición de los lenguajes de propósito general (C#, Java, UML).

– Permite diseñar abstracciones que forman parte de un dominio.

– Se focaliza en el problema de dominio y no en los detalles de implementación.

– Necesita proveer la sintaxis y semántica correcta al usuario.



Creando un Lenguaje Compartido> Vocabulario compartido

El experto de dominio se puede entender con quien lo modele

> Terminología común en los Test Cases

El experto de dominio podría verificar los casos.

> Vocabulario común durante el Desarrollo

El desarrollo resultante hablará en el mismo idioma que el lenguaje de Dominio.



Algunos ejemplos de DSL>SQL

>CSS>HTML

>RSpec>ANTRL

>Visualization & Modeling SDK (Visual Studio)>M Language



Tipos de DSL> Externos

– Lenguaje independiente.

– Standalone.

– Son muy expresivos y pueden leerse como si fuese inglés.

– Necesita de compiladores y analizadores.



Tipos de DSL> Internos

– Embebidos dentro del lenguaje.

– No son tan expresivos como los DSL Externos.

– Son más sencillos porque no usan compiladores externos.

– Hace que el lenguaje general parezca de uso específico.

– A veces ligado al concepto de «Fluent Interfaces»



DSL vs UML: O cuando utilizarlos

No hay una "mejor" que otra

– UML es de uso general. Puede contar con elementos innecesarios a nuestro problema.

– UML es lo más utilizado para transmitir ideas.

– UML es más fácil de implementar al inicio.

– UML se vuelve más complejo al extenderlo.

– DSL se ajusta a nuestro dominio.

– DSL se lleva mejor con los Code-Generators.

– UML puede trabajar de forma conjunta con DSL



Ejemplo de un DSL Visual> Vista de Diseño



Ejemplo de un DSL Visual> Vista del DSL del punto de vista del usuario

Padre

HijoRelación

Padre-Hijo

Podría luego generar código a parFr de este DSL



Fluent Interfaces– Es un tipo particular de API diseñada de forma «fluida»

– Facilitan el trabajo al implementar API que son más fáciles de leer y escribir.

– Pensar como expresar el DSL de manera lógica y autodescriptiva, de forma independiente a la funcionalidad real.

– Nos da la sensación de tener todo junto y conectado en vez de comandos desconectados.



Un ejemplo simple de legibilidad> Comunmente encontramos:

> Pero usando una Extensión Literal:

schedule.RepeatEvery = new TimeSpan(2,0,0);schedule.ExpiresIn = new TimeSpan(100,0,0,0);

schedule.RepeatEvery = 2.Hours();schedule.ExpiresIn = 100.Days();



Algunos ejemplos de Fluent> Fluent Assertionsstring actual = "ABCDEFGHI";

actual.Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9)

RuleFor(customer => customer.Surname).NotEmpty();

RuleFor(customer => customer.Forename).NotEmpty().WithMessage("Specify a First Name");

RuleFor(customer => customer.Discount).NotEqual(0).When(customer => customer.HasDiscount);

RuleFor(customer => customer.Address).Length(20, 250);

RuleFor(customer => customer.Postcode).Must(BeAValidPostcode).WithMessage("Specify a valid Postcode");

> Fluent Validations



BPM


Arquitectura de Proyectos ITBPM – Business Process Management

77

“Conjunto de las fases sucesivas de un fenómeno natural o de una operación artificial”

RAE“Un proceso de negocio es un conjunto de tareas

relacionadas lógicamente llevadas a cabo para lograr un resultado definido”

Wikipedia

¿Qué es un proceso?



78

¿Qué es una regla de negocio?

Describe políticas, normas, operaciones, definiciones y restricciones

Ejemplo: “Si a un cliente se le factura mas de $10000

mensualmente, es un cliente tipo A” “A los clientes tipo A se les hace un descuento del 15%

sobre facturas superiores a $3000”



79

¿Qué es BPM?

“Es un enfoque sistemático para mejorar los procesos de negocio de una compañía”

www.cio.com“… Una mezcla de administración de procesos con

tecnologías de integración… para dar soporte a una rica interacción humana y una profunda integración de

aplicaciones.” Gartner


http://www.cio.com/

http://www.cio.com/


80

Componentes de BPM como enfoque

Experiencia Disciplinas Organizacionales

Control y Management

Socios y Servicios



81

Componentes de BPM como suite SW

BPM Layer

Front end cliente Monitoreo y análisis

Diseño y simulación de procesos

Motor de procesos Motor de reglas

Monitoreo y adm

inistración

Capa SOA



82

BPM vs Otras soluciones

Aplicación separada

WorkflowDepartamental

Workflow Mul)departamental

BPM Empresarial

Ruteo de imágenes y documentación




Formularios electrónicos



Motor de reglas Motor de reglas

Broker de integraciónServicios de integración

PortalesPortales &

colaboración

Análisis de procesos

BAM

Manejo de eventos



83

BPM – alternativas en el mercadoOpen Source

World Class


http://www.bonitasoft.com/













¿Preguntas?



Bibliografía

>Architecture Journal 23

>Domain Driven Design - Eric Evans >DSL in Action - Debasish Ghosh

>Guía de Arquitectura N-CapasOrientada al Dominio con .NET 4.0


Documents

Modelando la Lógica de Negocio - APIT-UTNapit.wdfiles.com/local--files/start/03_apit_logica_de_negocio_2011... · Buenas Prácticas > Aislar el modelo Arquitectura típica en 4 capas