Introducción al patrón Bounded Context
¿Qué enfoque utilizar para la descomposición?
- Transaction Script (procedural): toda la lógica resida en scripts que normalmente están en BD.
- Table Module / Active Record (Orientado a los datos): la lógica de negocio está acoplada a las tablas de la BD.
- Domain Driven Design (Orientado al negocio): Manejar objetos de negocio
- Para microservicios, nos vamos a centra en DDD.
- DDD es una forma de pensar (mindset) las cosas. No solo se aplica al código, sino a difernetes áreas del desarrollo de software (análisis, diseño, pruebas, etc.).
- Tanto los enfoques "Transaction Script" y "Table Module" le dan mucha responsabilidad a la BD lo cual te deja ligado a la tecnología (alto acoplamiento).
Modelo de dominio
El modelo de dominio no es una representación directa de las de una BD. Múltiples tablas pueden decantar en una sola entidad de negocio. La recomendación es no poner lógica en la BD. Sin embargo, puede haber excepciones, como la reportería.
Características de DDD
- Software que modela dominios del mundo real (Expertos en dominios y desarrolladores de software)
- Muchas herramienas y técnicas
- Concept of bounded contexts
- El dominio consta de múltiples contextos delimitados (Cada BC representa una función de dominio)
- El Bounded Context fomenta bajo acoplamiento y alta cohesión.
Ventajas del modelo de dominio
- Gestionar complejidad
- Aprovecha los patrones de diseño
- Hablar el lenguaje del negocio
- Abstrae el equema de BD poco bonitas (nombres feos)
- Facilitación para equipos grandes
- Reutilizable
Desventajas del modelo de dominio
- Curva de aprendizaje
- Diseño que consume mucho tiempo
- Compromiso a largo plazo
- Gastos generales de mapeo de BD
Bounded Context
Una responsabilidad específica impuesta por un límite explícito.
- Identificar el concepto de dominio principal.
- Modelos internos (conceptos de apoyo)
- Cada BC tiene una interfaz explícita (entradas y salidas)
- Modelos compartidos para la comunicación
- Microservicio = Bounded Context
- Pertenece a un equipo
- Dueño de su propio almacén de datos
- Contratos (interfaces)
- Bounded Context es lógica
- Contextos externos (fuera del contexto)
Lenguaje Ubicuo
Lenguaje que pertenece a una función de dominio específica (Bounded Context). También utilizado por todos los miembros del equipo para conectar todas las actividades del equipo con el software.
- Para comunicarse correctamente con el experto de dominio.
- Cada subdominio va a manejar su lenguaje de negocio.
- Como arquitectos tenemos que hablar el lenguaje del negocio.
Bounded Context y Lenguaje Ubicuo
- El concepto principal define el lenguaje de dominio, es decir, el objetivo principal.
- Se usa como filtro de Bounded Context
- Conceptos en contexto
- Conceptos contexto externos (fuera del contexto)
- Quienes definen el lenguaje
- Expernos en dominios
- Desarrolladores de software
- Se recomienda usar un diccionar de negocio
Contextos sin límites
- Enfoque usualmente utilizado en el desarrollo tradicional.
- Se viola el principio de responsabilidad única
Ejemplo: Dominio de envíos
Establezco los dominios que forman parte de mi proceso de negocio:
Conceptos principales y conceptos de soporte.
Bounded Context como técnica
- Identificar los aspectos/conceptos clave del dominio
- Los conceptos forman los Bounded Contexts
- El concepto principal forma un lenguaje ubicuo
- Renombrar conceptos/modelos de soporte
- Renombrar los conceptos LU a natruales
- Mover a contextos externos (fuera de contexto) conceptos/modelos
- No es parte del lenguaje ubicuo
- Eliminar conceptos fuera de alcance
- Los conceptos individuales indican integración
- Integración con otros Bounded Context
Identificando el core (conceptos principales)
Conceptos fuera de contexto
Conceptos únicos indican integración
Bounded Context a Microservicios
¿Cuándo componer o realizar agregación de servicios?
- Servicios combinados
- Uso de descomposición (método de Bounded Context)
- Razones para la integración
- Informes
- Funcionalidad mejorada
- Usabilidad para clientes
- Performance
Granularidad de servicios
- Realización de las funciones de un proceso mediante la implementación de una gran cantidad de servicios detallados conduce a la reducción de los esfuerzos de desarrollo y mantenimiento. Además, un mayor potencial de reutlización de los servicios se puede lograr.
- Sin embargo, al mismo tiempo los costes de composición de (muchos) servicios aumentan. Cuanto más fina se la granualidad para realizar las funciones de un proceso, mayor es el número de servicios y más esfuerzo tiene que ser gastado en componerlos. Por el contrario, los servicios de grano muy grueso tienen las desventajas de mayores costos de implementación y menor potencial de reutilización.
Granularidad de servicios - Teraservices
- Los teraservices son lo opuesto a los microservicios
- El diseño de teraservices implica una especie de servicio monolítico. Los Teraservices requieren dos terabytes de memoria o más. Estos servicios se pueden utilizar cuando los servicios solo se requieren en la memoria y tienen un uso elevado.
- Estos servicios son bastante costosos en entornos de nube debido a la memoria necesaria, pero el costo adicional se puede compensar cambiando de servidores de cuatro núcleos a servidores de doble núcleo.
Granularidad de servicios - Microservices
- En los Microservices, los componentes de diseño no se agrupan y tienen acoplamientos flexibles.
- Cada servicio tiene sus propias capas y base de datos, y se agrupan en un archivo independiente para todos los demas.
- Todos estos servicios implementados proporcionan sus API específicas, como Clientes o Reservas. Estas API están listas para consumirse. Incluso la interfaz de usuario también se implmenta por separado y se diseña mediante el usuo de los servicios de la interfaz de usuario.
- Por esta razón, los microservicios proporcionan varias ventajas sobre su contraparte monolítica.
Granularidad de servicios - Nanoservices
- Los microservicios que son especialmente pequeños o detallados se denominan nanoservicios.
- Un patrón de nanoservicios es realmente un antipatrón.
- En el caso de los nanoservicios, las sobrecargas, como las actividades de comunicación y mantenimiento superar su utilidad.
- Se deben evitar los nanoservicios. Un ejemplo de un patrón de nanoservicios (anti) sería crear un servicio independiente para cada taba de base de datos y exponer su operación CRUD mediante eventos o una API REST.
Granularidad de servicios - Consejos para construir según TOGAF
- Supongamos que hay una línea horizontal imaginaria (eje x), que representa la línea de granularidad; el nivel adecuado determinado para MSA.
- Los servicios que están más cerca, o alrededor de esta línea (servicios dentro de la caja punteada), son buenos microservicios; aquellos que están muy por encima de esta tendencia de línea hacia la exhibición de características de los monolitos, y los que caen muy por debajo de la tendencia de línea hacia la exhibición de características de nanoservicios.
- Los problemas con los monolitos incluyen:
- Incluso los cambios pequeños y menores requieren la reconstrucción de toda la base de código y la re-implementación de la nueva compilación.
- Los ciclos de cambio (para varias funcioens y características) tendrán que estar unidos entre sí, lo que provocará una dependencia no deseada.
- Lograr una estructura modular dentro de un monolito es difícil de aplicar.
- El escalado se logra replicando toda la aplicación (aunque funcioens específicas pueden tener diferentes requisitos de escalabilidad).
- Los problemas con los nanoservicios incluyen:
- Las llamadas remotas son costosas (desde una perspectiva de rendimiento).
- La comunicación entre los servicios se vuelve habladora, lo que resulta en un sistema subóptimo.
- La explosión inmanejable de los servicios puede dar lugar a la proliferación de servicios, a una gobernanza desafiante.
Aplicando el patrón DDD a un microservicio
Notas:
- El ValueObject sirve para hacer validaciones que no son de negocio, por ejemplo, las validaciones de formato.
- Las validaciones de negocio son parte de la entidad.
Comments
Post a Comment