How To Split The Monolith - From monolith to microservices
0 recomendaciones285 vistas
Este documento describe estrategias para dividir un monolito en microservicios, incluyendo un enfoque de diseño impulsado por dominios. Explica cómo analizar los componentes, servicios, procesos y lógica de negocio de un sistema para identificar dominios de negocio y capacidades, y luego diseñar microservicios alineados con estos dominios. También cubre temas como estrategias de partición vertical, arquitectura de microservicios y diseño impulsado por dominios.
How To Split The Monolith - From monolith to microservices
- 1. How to Split the monolith? Oliver Fierro – Arquitecto de Soluciones https://cl.linkedin.com/in/oliverfierro A business and architecture overview https://www.meetup.com/Cloud-Native-Chile/
- 2. Índice Split the Monolith Product and Ecosystem Components, services and interrelations Split Strategies Vertical Split and considerations Domain Driven Design approach Business overview (industry and product) Domains, subdomains and business capabilities Microservices architecture and Domain Driven Design
- 3. Producto y Ecosistema Aplicación web Servicios SOA Procesos Lógica Funcional en Base de datos Modelo de datos Integración con otros sistemas Integración con canales WebApp SOA Database Functional Logic Database Model Process Intersystem integration channel integration
- 4. Producto y Ecosistema Aplicación web Analizar las funcionalidades o módulos actuales del aplicativo Las opciones del menú como guía inicial Reclasificarlos con algún criterio (dominios de negocio)
- 5. Producto y Ecosistema Procesos (por ejemplo ETL, Schedule) Mecanismo de sincronización por eventos y/o streaming
- 6. Producto y Ecosistema Lógica Funcional en Base de datos Analizar las reglas de negocio Analizar configuraciones Analizar los algoritmos Analizar los CRUD Analizar Trigger y vistas
- 7. Producto y Ecosistema Modelo de Datos Analizar modelo relacional: Tablas y relaciones Proponer un modelo de datos alternativo y desagregado Eres dueño de la información o tienes control sobre ella? Lo maneja un repositorio de datos? Lo maneja un sistema cerrado? Puedes acceder a través de un servicio? (WS, Rest, Otro)
- 8. Producto y Ecosistema Tu verdadero problema está en la lógica de la base de datos o de tu aplicación.
- 9. Servicios SOA Construir API’s equivalentes API Layer Business Layer Data Layer Servicio 1 API Layer Business Layer Data Layer API Layer Business Layer Data Layer API Layer Business Layer Data Layer API Layer Business Layer Data Layer API Layer Business Layer Data Layer API Layer Business Layer Data Layer Servicio 2 Servicio 3 Servicio 4 Servicio 6Servicio 5 Middleware A qué capacidad de negocio pertenece? Tiene el nivel de abstracción adecuado? Cumple los principios para ser considerado un microservicio? Es reutilizable? Monolith Split Strategy
- 10. API Layer Business Layer Data Layer DataBase Repository Business Logic API Monolith Split Strategy
- 11. Disponibilidad de Entrega de Productos Cobertura Despacho Servicio SOA Saldo Productos Tipos de Servicio Rangos Horarios Costos del Despacho Fechas de entrega Red Logistica Gestión Stock Costing Servicios Entrega Monolith Split Strategy
- 12. Monolith Split Strategy WAR 1 WAR 2 WAR 3 EAR Store Procedures Tables DataBase Monolitic Traditional FrontEnd/Bussines Layer Monolitic BackEnd WAR 1 Functional FrontEnd/Bussines Layer WAR 2 WAR 3 Application Server Application Server Application Server Application Server
- 13. Store Procedures Tables DataBase Monolitic BackEnd WAR 1 Functional FrontEnd/Bussines Layer WAR 2 WAR 3 Application Server Application Server Application Server WAR 1.1 Rest WAR 1.2 Rest WAR 1.3 JMS Service API/Bussines Layer WAR 2.1 EJB WAR 2.2 EJB Application Server Monolith Split Strategy
- 14. Store Procedures Dominio 1 Dominio 2 Dominio 3 Tablas DataBase Monolitic Modern FrontEnd Monolític BackEndFunctional Microservices Container Container UI DANGER: Microservicios que sin darte cuenta acceden a datos de otros dominios de negocio! Monolith Split Strategy
- 15. Lógica Store Procedures Dominio 1 Dominio 2 Dominio 3 Tabla 1 DataBase Monolitic Modern FrontEnd Monolític BackEnd Microservices Container Container UI Tabla 2 Tabla 4 Tabla 5 Tablas privadas por dominio Schemas por dominio Base de datos por dominio Monolith Split Strategy Tabla 3
- 16. Domain Driven Design • Business Domain: Dimensión o contexto de negocio delimitado que puede estar dado por un dominio, subdominio o capacidad de negocio. • Industry (backbone) SupplyChain, Bancos, Seguros • Product Aplicativo Web, Servicios, ERP, Sistema standalone
- 17. Domain Driven Design Key Differentiator CORE Supporting Generic Business complement Indirect relation
- 18. Domain Driven Design El macro dominio es el negocio asociado a una industria en particular (retail, banca, aeronáutica) donde se desenvuelve éste. Los dominios del negocio son grandes áreas (estratégicas, tácticas u operacionales) del negocio que le agregan valor, dentro del contexto del negocio e industria. Cada dominio se divide en subdominios que corresponden a partes esenciales que contribuyen a un dominio determinado agrupados por un criterio de negocio. Cada subdominio se divide en un conjunto de capacidades de negocio, las cuales contribuyen en su conjunto al subdominio Cada subdominio a su vez es compuesto por un set de funcionalidades.
- 19. Domain Driven Design Domain 1 SubDomain 1 SubDomain 2 SubDomain 3 Business Capability 1 Business Capability 2 Business Capability 3
- 20. Domain Driven Design Business Capability 1 Process 1 Process 2 Process 3 Process 4 Funct1 Funct2 Funct3 Funct4 Funct5 Funct6 Funct7 Funct8 Funct9 Funct10 Funct11 Funct12 Funct13 Funct14 Funct15 Funct16
- 21. Domain Driven Design Logistic Chain Manage Offer Manage Storage Manage Order Manage Inventory Manage Delivery Manage Shipping Cost Manage Transport Manage Tracking Manage Routing Manage Operations Supply Chain Logistic DeliveryProcurement Management Import Management
- 22. Domain Driven Design Boarding Manage CheckIn Manage Reservation Manage Loyalty Manage Payment Manage Product and Service Manage Change and Devolution Manage Customer Manage Customer Pax Loyalty CRM Pax Insights Pax Ops Departure Control IROPS Partnership Accural
- 23. Domains & Capabilities Map
- 24. Building Block of DDD Entity – an object with a persistent identity. Two entities whose attributes have the same values are still different objects. In a Java EE application, classes which are persisted using JPA @Entity are usually DDD entities. Value object – an object which is a collection of values. Two value objects whose attributes have the same values can be used interchangeably. An example of a value object is a Money class, which consists of a currency and an amount. Factory – an object or method that implements object creation logic which is too complex to be done directly by a constructor. A factory might be implemented as a static method of a class. Repository – an object that provides access to persistent entities and encapsulates the mechanism for accessing the database. Service – an object that implements business logic which doesn’t belong in an entity or a value object. Agregations – A cluster of entites and values. These objects are viewed together as a unified whole from a data modification perspective. Every aggregate has a specific root and border.
- 25. Building Block of DDD Agregations Business Entities Services Repositories Value Objects Factories Layered Architecture Bounded Context Ubiquitous Language Business Capabilities
- 26. Building Block of DDD
- 28. From DDD to Microservices Domain: Operations Subdomain: SupplyChain Business Capabilities: • Procurement Management • Import Management • Logistic Delivery Availability Manage Stores Chain Storage Manage Transport Manage Costing& Pricing Stock Manage Tracking Picking Routing Order Manage
- 30. Dominios de Negocio ¿Qué queremos ofrecer a nuestros consumidores de servicios? Toda la información de nuestro backend o sólo una parte? Delegaremos una parte de la responsabilidad de las reglas de negocio al consumidor o nos haremos cargo nosotros del control de las reglas de negocio, orquestaciones y necesidades particulares de cada uno de ellos?
- 31. Domain Driven Design Domain Driven Design + Microservices Architecture
- 32. How to Split the monolith? Oliver Fierro – Arquitecto de Soluciones https://cl.linkedin.com/in/oliverfierro A business and architecture overview https://www.meetup.com/Cloud-Native-Chile/