Las arquitecturas de microservicios están muy de moda en la actualidad. La pregunta de cuán pequeño puede ser un microservicio se hace regularmente. ¿Es el micro lo suficientemente pequeño? ¿Podemos construir pico-servicios? En , hemos elegido ir en una dirección diferente. Nos estamos centrando en el tamaño del equipo.
Para maximizar el rendimiento, ¿qué tamaño debe tener un equipo? Un par de desarrolladores… Diez pares de desarrolladores… Por el momento, hemos establecido dos o tres pares de desarrolladores con un director de producto, un especialista en UX y un ingeniero de desarrollo… Dada esta estructura de equipo, nos preguntamos ¿qué tamaño puede tener una parte de nuestro sistema que ese grupo realmente posea?
Si la creación de una nueva característica requiere la coordinación de varios equipos, habrá preguntas constantes sobre quién debe ser alertado cuando haya un problema a las 3:00 am.
En , un Contexto Limitado es una parte del sistema general que puede ser propiedad de un solo equipo. Un Contexto Limitado tiene límites claros. Al estar apoyado por un Equipo de Producto, puede ser considerado un producto separado por derecho propio.
Características técnicas de los contextos delimitados
Acceso exclusivo a su(s) almacén(es) de datos
Esto significa que ningún otro equipo o servicio o Contexto Limitado puede acceder a la(s) base(s) de datos utilizada(s) por este Contexto.Esta encapsulación de datos permite al equipo evolucionar sus esquemas más fácilmente ya que no tiene que coordinarse con otros equipos.También permite al equipo cambiar la tecnología de almacenamiento de datos por completo.Puede pasar de archivos planos a Postgres a Redis a Cassandra y viceversa según cambien las necesidades del cliente.
Oleoducto de construcción independiente
Los equipos pueden utilizar la construcción compartida y desplegar servidores, pero tienen una construcción independiente para su Contexto Limitado. Los Contextos Limitados también proveen hardware exclusivo (virtual) en nuestra compañía de hospedaje, lo que les permite validar y desplegar sus componentes del sistema en su propia cadencia sin interferir o poner en riesgo otras partes del sistema general.
Unidades desplegables
Un Contexto delimitado consiste en uno o más componentes como sitios web, APIs HTTP, servicios/demonios de Windows, aplicaciones, etc. Todos estos componentes están construidos para apoyar el propósito general del Contexto delimitado y el equipo es responsable de las interacciones entre ellos.
Modelo de Dominio Unificado
El equipo puede crear un modelo del dominio dentro del Contexto Limitado que incluye todas las reglas de esta parte del sistema sin preocuparse por el resto del sistema, lo que permite modelos muy afinados y expresivos que pueden mejorar la comunicación y la productividad.
Patrones de comunicación
Los Contextos Limitados son parte de un sistema mayor. No prescribimos la arquitectura ni los patrones de comunicación dentro del Contexto Limitado. En su lugar elegimos confiar en que el equipo de profesionales que posee el Contexto hará buenas elecciones. Tenemos algunas reglas simples para la comunicación entre los Contextos Limitados.
Favorecer la comunicación asíncrona
Desacoplamos temporalmente los contextos de cada uno de ellos siempre que sea posible, lo que se consigue pasando mensajes en formato JSON que representan eventos empresariales a través de un agente de mensajes de publicación/suscripción, lo que permite a cada contexto limitado producir estos eventos a la velocidad adecuada sin preocuparse por la disponibilidad de los consumidores. Las colas permiten a cada sistema de suscripción nivelar la carga de mensajes entrantes y escalar a los consumidores para satisfacer esa carga. Los equipos almacenan en caché los eventos empresariales que necesitan en sus propios almacenes de datos para poder ejecutar rápidamente la lógica empresarial sin depender de recursos externos (a su contexto limitado).
API del sistema
Algunas operaciones no encajan bien en un enfoque asíncrono, en concreto, se trata de operaciones muy algorítmicas o que se basan en datos con un alto grado de estado. Entre los ejemplos se incluyen el cálculo de los resultados de la búsqueda (imagínese que se almacenan en caché los resultados de todas las búsquedas posibles), el cálculo de la siguiente pregunta en un motor de evaluación dinámica, la asignación de un recurso limitado, como un número limitado de puestos de prueba beta, etc. En estos casos, los contextos limitados exponen API HTTP+JSON que pueden ser consumidas por otros contextos limitados del sistema.
Entrega, Autonomía, Responsabilidad, Innovación
Al construir nuestro sistema como una colección de Contextos delimitados, hemos establecido cada equipo para que tenga éxito en la entrega de un producto de calidad a nuestros clientes.La mayoría de nuestros equipos son totalmente responsables de un pequeño número de Contextos delimitados. Esta propiedad permite a nuestros ingenieros asumir la responsabilidad que, a su vez, anima a nuestro liderazgo a confiar en nuestros ingenieros con una mayor autonomía. Una mayor autonomía conduce a una mayor innovación dentro de los Contextos delimitados, ya que intentamos deleitar regularmente a nuestros clientes.
Categorías: technicalTags: architecture, cross-functional