Ir al contenido principal

SOA: Una analogía orientada al servicio.

Antes de iniciar a crear aplicaciones, componentes y patrones complejos, primero entendamos principios básicos y problemas comunes:

1. Fundamentos:
Lo que distingue este enfoque es la manera en que logra la separación. Lo que esto significa es que la lógica requerida para resolver un gran problema es mejor si se descompone en una colección de piezas más pequeñas y relacionadas. Cada una de estas piezas aborda una específica del problema (Responsabilidad).

Una analogía orientada al servicio: Para entender está arquitectura, hagamos una analogía contra un ciudad capital (Una ciudad relativamente grande).


  •  Las empresas dentro de la ciudad están orientadas al servicio, ya que cada una proporciona un servicio distinto que puede ser utilizado por múltiples consumidores. Colectivamente, estas empresas comprenden una comunidad empresarial. Tiene sentido que una comunidad de negocios no sea atendida por una sola empresa que brinde todos los servicios. Al descomponer la comunidad en puntos de venta especializados, logramos un entorno en el que estos puntos de venta se pueden distribuir.
  • Si establecemos dependencias dominantes, podríamos inhibir el potencial de las empresas individuales. Si bien queremos permitir que los puntos de venta interactúen y aprovechen los servicios de los demás, queremos evitar un modelo en el que los puntos de venta formen conexiones estrechas que den como resultado interdependencias restrictivas. Al empoderar a las empresas para que sean "dueñas" de sus servicios individuales, les permitimos evolucionar y crecer relativamente independientes entre sí.
  • Aunque fomentemos la independencia dentro de nuestros puntos de venta, aún debemos asegurarnos de que acepten adherirse a ciertos estándares, por ejemplo, una moneda común para el intercambio de bienes y servicios,

Conclusiones:
  • No todos los puntos de venta (servicios) son del mismo tamaño.
  • Varios puntos de venta pueden ofrecer los mismos servicios.
  • Si un punto de venta cierra, hay otros que lo pueden atender (Disponibilidad)
  • La comunicación e intercambio de mercancía o medio de pago son estándares (Mantenibilidad)
  • Podemos colocar un letrero de que el punto de venta esta cerrado (Control de Fallas)
  • Si la demanda aumenta, crezco el punto de venta o creo más (Escalabilidad)

Que otras conclusiones se te ocurren?


Referencias:
Service-Oriented Architecture Concepts, Technology, and Design, Tomas Earl.


Comentarios

Entradas más populares de este blog

Antipatrones Microservicios

1. Migración de Manejo de Datos Antipatron. El antipatrón de migración basado en datos se produce principalmente cuando se migra de una aplicación monolítica a una arquitectura de microservicios. La razón por la que esto es un antipatrón es que al principio parece una buena idea migrar la funcionalidad del servicio y los datos correspondientes al crear microservicios, pero como aprenderá en este capítulo, esto lo llevará por un mal camino que puede resultar en alto riesgo, exceso de costo y esfuerzo de migración adicional. Comprender los riesgos relacionados con la migración de datos y la importancia de "datos sobre funcionalidad" es el primer paso para evitar este antipatrón. La técnica para evitar este antipraton consiste en realizar primero una migración de la funcionalidad, es decir, primero refactorizar el código fuente, pasando por primero modularizar el contexto o dominio y continuar con la definición y construcción de servicios, a medida que se conoce el código que se...

Microservice Architecture | Arquitectura de microservicios

Qué es  Arquitectura de microservicios ?   El estilo arquitectónico de microservicios es un enfoque para desarrollar una sola aplicación como un conjunto de pequeños servicios, cada uno de los cuales se ejecuta en su propio proceso y se comunica con mecanismos ligeros, a menudo una API de recursos HTTP. El hecho de que los  servicios son implementables y escalables de manera independiente, cada servicio también permite que se escriban diferentes servicios en diferentes lenguajes de programación. También pueden ser gestionados por diferentes equipos. Las aplicaciones creadas a partir de microservicios pretenden ser lo más desacopladas y cohesivas posible: poseen su propia lógica de dominio y actúan más como ltros en el sentido clásico de que reciben una solicitud, aplican la lógica según corresponda y producen una respuesta. Un servicio es una funcionalidad que se expone para su uso por otros procesos .  Que otros protocolos puedo us...

Referencia | Material de Apoyo

Arquitectura .NET Architecture Guides Architectural Patterns: Uncover essential patterns in the most indispensable Domain Driven Design Quickly Microservicios Practical Microservices: By Umesh Ram Sharma Building Microservices: Designing Fine-Grained Systems By Sam Newman SOA Design Patterns By Thomas Erl