How to split the monolith. An approach Domain Driven Design and 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

27. Principles of Microservices

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/