APIs y MicroServicios en Empresas Monolíticas — Diseño guiado por el dominio— Domain Driven Design #4
Cuando buscamos información de microservicios en internet, siempre encontraremos toneladas de stacks tecnológicos para poder desarrollar microservicios, pero muy, muy poco de como diseñar y establecer patrones de comunicación que son escenciales desde su concepción, en mi experiencia muchas veces el enfoque es más tecnologico que meramente tener buenos escenarios, donde podamos aplicar este estilo de arquitectura.
Si bien los microservicios se componen de muchos de los patrones de diseño que hemos aprendido a través del tiempo como desarrolladores de software, esto va más alla.
En nuestra busqueda sobre microservicios encontraremos el concepto de: DDD (Domian Drive Design), donde hablaremos un poco aquí.
¿Qué es el dominio?
Área temática o campo a la que un usuario aplica software para su funcionamiento.
¿Qué es el modelo de dominio?
Representa la terminología y los conceptos clave del dominio del problema, identifica las relaciones entre las entidades incluidas dentro del ámbito del dominio del problema, sus atributos y proporciona una visión estructural del dominio.
Domain driven design es un enfoque para el desarrollo de software definido por Eric Evans en su libro Domain-driven design: Tackling Complexity in the Heart of Software, que se centra en un modelo rico, expresivo y en constante evolución para resolver problemas del dominio de una forma semántica.
Lenguaje común (Ubiquitous language)
Es muy comun tener problemas de comunicación que surgen durante el desarrollo de proyectos software, esto entre los desarrolladores y los “expertos” del dominio.
aja, si claro.
Los expertos del dominio tienen un amplio conocimiento sobre el dominio, los desarrolladores entendemos y manejamos la terminología técnica, sin embargo, habitualmente nuestro conocimiento sobre el dominio del problema es bastante limitado.
Esta diferencia de lenguajes y conocimientos, normalmente da lugar a situaciones en las que los expertos del dominio, describen de manera confusa y ambigua, qué esperan del sistema.
En proyectos donde no existe un lenguaje común, nos vemos obligados a realizar un proceso de traducción para poder comunicarnos con los expertos del dominio.
A su vez, los expertos del dominio tienen que realizar un proceso de traducción en sentido opuesto para comunicarse con los desarrolladores.
Cada vez que se realiza una traducción se malinterpretan y confunden conceptos, provocando que diferentes miembros del equipo entiendan conceptos de manera diferente, y lo que es aún peor, sin ser conscientes de ello, aveces…
estas malas interpretaciones hacen que el software contenga incoherencias, y contradicciones dentro del código que provocarán errores en el sistema.
El proceso para llegar a un lenguaje común es iterativo, con ello deberemos ejercitar el lenguaje y pulirlo tanto en diagramas, como en escrito, y especialmente en la comunicación verbal. esto hará que el lenguaje vaya evolucionando y cambiando.
Dichos cambios deben verse reflejados en el código, por lo que debemos de ir refactorizando dicho código para que refleje los cambios que se producen en el lenguaje.
ajaaa y los microservicios apa? que tiene que ver todo esto?
Los microservicios deben diseñarse alrededor de las funcionalidades de la empresa, no en capas horizontales como el acceso a datos o la mensajería
Además, deben tener un acoplamiento flexible y una alta cohesión funcional,
si puedes cambiar un servicio sin necesidad de que los demás se actualicen al mismo tiempo, vas por el camino correcto!!
Un microservicio es coherente si tiene un propósito único y bien definido, como administrar las cuentas de usuario o realizar el seguimiento del historial de entregas, generar creditos bancarios, captar nuevos clientes. etc.
Análisis del dominio,
Te comparto una forma en la que puedes diseñar tus microservicios, una vez que ya sabes que es DDD.
- - Es necesario generar una visión general del sistema que se va a crear o migrar, generando un modelo de dominio, este es un modelo abstracto del ámbito empresarial, extrae y organiza el conocimiento del dominio, y proporciona un lenguaje común para los desarrolladores y los expertos en los dominios.
2.-Con el diseño basado en dominios, empieza por modelar el dominio empresarial y crea un modelo de dominio.
El modelo de dominio es un modelo abstracto del ámbito empresarial.
3.- Empieza por asignar todas las funciones empresariales y sus conexiones, probablemente esto requerirá la colaboración de los expertos en dominios, los arquitectos de software y otros actores implicados, crea un diagrama “smart cases” o genera una pizarra con los dominios encontrados.
Podemos hacer uso de smart cases, los cuales nos ayudarán a poder modelar los diferentes flujos o customer journeys que establecerán nuestros microservicios para soportar los diferentes productos.
Esto lo abordaremos en los siguientes artículos donde hagamos todo el proceso de diseño de microservicios de un producto en especifico.
4.- A medida que generes el diagrama, empieza a identificar subdominios discretos.
¿Qué funciones están estrechamente relacionadas?
¿Cuáles son funciones fundamentales para la empresa y cuáles proporcionan servicios auxiliares?
¿Cuál es el gráfico de dependencias?
5.-Ten en cuenta que, en este punto del proceso no hemos tomado decisiones sobre la implementación o las tecnologías. Algunos de los subsistemas pueden implicar a sistemas de software externos o servicios de terceros.
Aun así, la aplicación requiere interactuar con estos sistemas y servicios, por lo que es importante incluirlos en el modelo de dominio.
6.- Cuando una aplicación depende de un sistema externo, existe el riesgo de que el esquema de datos o la API del sistema externo se infiltren en la aplicación, poniendo en peligro a la larga el diseño de la arquitectura.
Esto ocurre especialmente con sistemas heredados que pueden no seguir procedimientos modernos y podrían usar esquemas de datos complejos o API obsoletas. En ese caso, es importante contar con un límite bien definido entre dichos sistemas externos y la aplicación. Debes considear el uso del patrón Strangler o del patrón Anti-Corruption Layer para este propósito.
En el siguiente artículo diseñaremos desde 0 un producto con microservicios apoyandonos de DDD para indetificar los dominios del producto. siguiendo la siguiente metodología y con el uso de smart cases.
— — — — — — — — — — — — — — — — — — — — — — — — — —
Todo el año 2021 estaré impartiendo diferentes tranings, bootcamps y workshops de Apigee, Cloud y Microservicios en APIXCLOUD Service y Certificatic en la CIUDAD DE MÉXICO, les comparto el link donde vienen los telefonos y redes sociales de contacto.
BOOTCAMP : ARQUITECTO EN APIs CON APIGEE Y MICROSERVICIOS CLOUD NATIVE:
🔻 Sede: APIX&CLOUD — Services / MODO ONLINE CON INSTRUCTOR EN TIEMPO REAL
🏆 Instructor: Jovani Arzate
⏰ Horario: 8:00am a 2:00pm.
⏳ Duración: 64 Horas dividido en 10 sesiones tomando 6 horas cada domingo.
🔻SOLO 15 LUGARES
📲 Contáctanos 👉 wa.link/v22o0v
contacto@apixcloudservice.com
Temas que se verán en el entranamiento:
1. APIs — APIficando productos digitales
2. APIs — OpenAPI Spec 2.0 y 3.0
3. Gobierno de APIs, Metodología, Roles
4. API Management, Desarrollo en Apigee, CI/CD
5. Monolíticos, Arquitectura SOA y principios de diseño
6. Contenedores, despliegue y CI/CD
7. Microservicios — patrones de diseño, arquitectura y desarrollo
8. Kubernetes para despliegue de microservicios
#openapi #apificacion #apidevelopers #certificatic #microservices #k8s #containers #apis #apigee #patterns #domaindrivendesing #cloudnative #docker #servicediscovery #tracing #logs #monitoring #faulttolerance #eventdriven #scaling #apigateway #servicemesh #governance #arquitectura #cloud #12factores #contractfirst #apifirstdevelopment #rest #swagger #microservicios
Jovani Arzate Cabrera| Entrepreneur | Public Cloud Specialist | Cloud Governance | API Evangelist | API Architect | Apigee | Microservicios | AWS | Azure | GCP
