logica de negocio ddd arquitectura de software

Modelando la Lógica de Negocio
Ing. Juan M. Arias
2011
Arquitectura de Proyectos IT
UTN - FRBA
Domain Model
DDD
Layers
Hexagonal Arch.
SoC
DSL
Wednesday, May 4, 2011

Agenda
> Introducción
> Domain Model
> Domain Driven Design
> Capas
> Alternativas a las Capas
> Mecanismos de Separación
> DSL
> BPM

Introducción

Introducción
Algunos tipos de Arquitectura
> Sociales
> Móviles
> Games
> Empresariales
4

Introducció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
5

Domain Model

Domain 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.
7

Domain Model
¿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.
8

Domain Model
Componentes
Abstracció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
9

Domain Model
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
10

Domain Model
Principios claves de Diseño
Single Responsability Principle
Open Close Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
> SOLID
11

Domain Model
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)
12

DDD
Domain Driven Design

DDD - 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.
14

El Problema de la Comunicación
Quiero 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?
15

Lenguaje Ubicuo
Traducir
Domain
Expert
Technical
Expert
Refinar
Acordar
Jerga
Jerga
16

Lenguaje Ubicuo
Domain
Expert
Technical
Expert
Lenguaje
Ubicuo
Bounded
Context
Bounded
Context
Bounded
Context
17

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
18

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
19

Buenas Prácticas
> Aislar el modelo Arquitectura típica en 4 capas
User Interface
Applica:on
Domain
Infraestructure
20

Layers

Layers - 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
22

Layers - Capas
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 Record
Data Mapper
Table Module
23

Layers - Capas
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
24

Layers - Capas
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
25

Layers - Capas
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 caso
de contar con dichos objetos.
26

Layers - Capas
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
27

Layers - Capas
Capa de Servicios
Servicios
Servicio
Aplicación Aplicación Aplicación
28

Layers - Capas
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:
MVC
MVP
MVVM
29

Layers - Capas
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:
Seguridad
Cache
Logging
Validaciones de Input
30

Layers - Capas
Capa de Infraestructura Transversal
> Radiografía de una aplicación no modularizada
> Radiografía de una aplicación modularizada
31

Layers - Capas
Persistence
Domain
Applica:on
Service
Presenta:on
Database
Transversal
32

Layers - Capas
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))es
Core
Domain Services
Core
33

Layers - Capas
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))es
Core
Domain Services
Core
34

Layers - Capas
Persistence
Domain
Applica:on
Service
Presenta:on
Database
Transversal
Caching
Security
Logging
IoC Repository
Applica)on Services
DTOs
Model
Controller
View
Web
En))es
Core
Domain Services
Core
Aunque a veces encontramos esto…!!
35

Layers - Capas
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!
36

AlternaFvas a las Capas

Alternativa 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
38

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

Domain
Mock DB
UI
Unit Test
DB
App
Aislamiento por medio de Interfaces
40

> Metodología
Aplicación
Mock DB DB Access
Tests User UI
1 2 3 4
41

Domain
DB
Mock DB
42

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
43

Transaction Script
User Interface
Services
Infraestructure
> Diseño
44

Transaction Script
Servicio
UI DB
Nombre
Apellido
Edad
45

Transaction Script
46

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.
47

Transaction Script
> Comparación con un modelo en capas
Esfuerzo
Complejidad de la lógica de Dominio
Transaction
Script
Domain
Model
48

Separación de la Lógica
Mecanismos de

Mecanismos 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.
50

Mecanismos de Separación
> Separación Programática
> Separación Declarativa
> Separación Introspectiva / Reflexiva
51

Separación Programática
– Separación de responsabilidades mediante distintos
objetos que se envían mensajes entre sí.
Objeto de
Negocio
DAO
52

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.
53

> 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” />
54

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

> Beneficios de utilizar Aspectos
Sin Aspectos
Con Aspectos
56

> 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.
57

> Aspectos típicos de una aplicación
– Seguridad
– Cache
– Gestión de Configuración
– Gestión de Excepciones
– Logging
– Validaciones de datos de entrada
58

> 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
59

> 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
60

> 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
61

Separación Introspectiva / Reflexiva
– Puedo manipular la lógica utilizando Reflection.
– Modifica el comportamiento de mi aplicación.
– Me permite extender mi aplicación.
Dominio
nuevo
Comportamiento
62

DSL
Domain Speciﬁc Language

DSL – 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
64

¿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.
65

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.
66

Algunos ejemplos de DSL
>SQL
>CSS
>HTML
>RSpec
>ANTRL
>Visualization & Modeling SDK (Visual Studio)
>M Language
67

Tipos de DSL
> Externos
– Lenguaje independiente.
– Standalone.
– Son muy expresivos y pueden leerse como si fuese
inglés.
– Necesita de compiladores y analizadores.
68

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»
69

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
70

Ejemplo de un DSL Visual
> Vista de Diseño
71

Ejemplo de un DSL Visual
> Vista del DSL del punto de vista del usuario
Padre
Hijo
Relación
Padre-Hijo
Podría luego generar código a parFr de este DSL
72

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.
73

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();
74

Algunos ejemplos de Fluent
> Fluent Assertions
string 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
75

BPM

BPM – 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

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
administración
Capa SOA

82
BPM vs Otras soluciones
Aplicación
separada
Workﬂow
Departamental
Workﬂow
Mul)departamental
BPM Empresarial
Ruteo de imágenes y
documentación
documentación
documentación
documentación
Formularios
electrónicos
Formularios
electrónicos
Formularios
electrónicos
Motor de reglas Motor de reglas
Broker de integración
Servicios de
integración
Portales
Portales &
colaboración
Análisis de procesos
BAM
Manejo de eventos

83
BPM – alternativas en el mercado
Open Source
World Class

¿Preguntas?

Bibliografía
>Architecture Journal 23
>Domain Driven Design - Eric Evans >DSL in Action - Debasish Ghosh
>Guía de Arquitectura N-Capas
Orientada al Dominio con .NET 4.0
85

logica de negocio ddd arquitectura de software

Recomendados

Recomendados

Más contenido relacionado

Similar a logica de negocio ddd arquitectura de software

Similar a logica de negocio ddd arquitectura de software (20)

Último

Último (20)

logica de negocio ddd arquitectura de software