Hemos pensado mucho y nos hemos esforzado en desarrollar las prácticas de ingeniería que utilizamos cada día. Estas prácticas se basan en principios que hemos llegado a valorar y esos principios conducen a las prácticas. Hemos documentado esos principios y prácticas en nuestro documento de Ingeniería. En el lado izquierdo de cada página hay un principio que valoramos, y en el lado derecho hay una lista de elementos que Hacemos , Fomentamos , y Evitamos .Este post se va a centrar en el principio: Articulamos nuestro sistema para apoyar a equipos responsables y autónomos.
Lo que hacemos
Para apoyar la arquitectura responsable de nuestro sistema de autonomía, aquí están las prácticas que pedimos a todos los ingenieros que adopten:
Construimos contextos altamente cohesivos, vagamente acoplados y delimitados. Hay tres conceptos importantes en esta declaración: Contextos altamente cohesivos, vagamente acoplados y limitados. Empezaremos con el último – Contextos Limitados. El concepto de un contexto limitado proviene del Domain Driven Design y abarca en gran medida la idea de dividir estratégicamente un sistema más grande y complejo en subsistemas más pequeños y manejables.
Una ventaja importante de los contextos delimitados es que, a medida que los sistemas alcanzan un cierto tamaño, se hace cada vez más difícil tener un modelo unificado que funcione en una gran base de código y una gran base de datos, etc.Aquí es donde entra en juego la parte poco acoplada: creamos un acoplamiento muy suelto entre contextos delimitados que permite que cada contexto tenga sus propios datos y modelos de código. Cada contexto también tiene su propia base de datos y si los datos de un contexto acotado se necesitan en otro contexto acotado, preferimos compartir esos datos asincrónicamente a través de la mensajería pub/sub. En algunos casos necesitamos permitir la comunicación sincrónica a través de las API, pero en ningún caso permitimos que un contexto acotado hable directamente con la base de datos de otro contexto acotado, lo que empuja la integración de los contextos acotados a los límites del sistema, donde se publican o consumen los mensajes o se exponen las API.
Con las piezas de integración empujadas hasta los bordes, esto permite que los interiores de los contextos delimitados estén aislados y sean cohesivos. Los contextos delimitados son cohesivos porque todo lo que se necesita para ofrecer una experiencia al usuario desde el diseño hasta la producción está contenido dentro de ese contexto delimitado.
Dividimos nuestro producto en rebanadas verticales completas. Una rebanada vertical significa que todo, desde la base de datos hasta la interfaz de usuario, está contenido en un único contexto delimitado. Contrasta esto con la división del sistema horizontalmente, donde se podría terminar, por ejemplo, con una aplicación de front-end y servicios de back-end. Dividir el sistema horizontalmente significa que los contextos delimitados (y por tanto los equipos) están altamente acoplados entre sí.si un equipo posee la interfaz de usuario y otro equipo posee la API de back-end para esa interfaz, entonces el equipo de front-end se bloquea cada vez que necesita cambios en la API.
Cuando se divide un sistema verticalmente, se encuentran costuras dentro del sistema y se dividen verticalmente de tal manera que todo, desde la base de datos hasta el front-end, está contenido dentro del contexto delimitado. Cuando se combina esto con contextos delimitados cohesivos y libremente acoplados, se crea un ambiente que escala porque cada equipo puede trabajar de manera autónoma con muy poca fricción entre los equipos. Se pueden seguir creando equipos y mientras la complejidad general del sistema aumenta, la complejidad local para cada equipo se minimiza y cada equipo puede ejecutarse mayormente de manera independiente.
Colaboramos con nuestro equipo de arquitectura en el diseño de sistemas. Nuestro equipo de arquitectura es en gran medida una organización de apoyo en lugar de una autoridad dictatorial. Ciertamente tienen opiniones sobre y proporcionan orientación a los equipos sobre cómo deben arquitecturar sus sistemas, e idealmente los equipos están llegando a sus arquitectos en busca de apoyo, pero en última instancia, la arquitectura interna de un contexto delimitado depende de los equipos. Dicho esto, el equipo de arquitectura es el propietario de la arquitectura general del sistema, ya que hay importantes decisiones arquitectónicas que afectan a todos los equipos, especialmente debido a la complejidad global creada por nuestros contextos delimitados y poco acoplados. Todos estamos de acuerdo en trabajar con el equipo de arquitectura en los aspectos que afectan al sistema a nivel mundial, como la forma en que nos comunicamos entre contextos delimitados. También involucramos a nuestros arquitectos cuando hacen grandes cambios internos en un contexto limitado para buscar su aporte.
Seguimos nuestro radar tecnológico. Esta es una pieza de nuestro documento de Ingeniería @ que tal vez necesita ser actualizado ligeramente.Nuestro radar tecnológico utilizado para determinar qué tecnología y herramientas, etc. se permitieron en… Recientemente hemos empujado gran parte de esa autoridad de toma de decisiones a los equipos y sus unidades de negocio asociadas. Pero usamos nuestro radar tecnológico como una guía.El radar tecnológico muestra qué tecnologías, lenguajes, herramientas, marcos, etc. se utilizan y con qué amplitud. Valoramos la autonomía, pero también fomentamos la responsabilidad. Los equipos deben consultar el radar tecnológico, el equipo de arquitectura cuando consideren qué tecnologías van a utilizar dentro de un contexto delimitado.Para ser buenos ciudadanos dentro de nuestra organización, tenemos que considerar cómo nuestras decisiones pueden afectar a la organización y al conjunto. Aunque preferimos crear una simplicidad local para los equipos, tenemos que estar seguros de que no estamos comprometiendo todo el sistema por un exceso de optimización a nivel local.
Participamos en el gremio de la arquitectura. Los gremios son grupos de personas que comparten un interés común y por lo tanto crean un gremio donde pueden hablar y aprender juntos. El gremio de arquitectura es un lugar para discutir las preocupaciones arquitectónicas que afectan al sistema en su conjunto. Este gremio es una oportunidad para compartir preocupaciones transversales que es importante que cada equipo conozca. Pedimos que un miembro de cada equipo asista regularmente. Cualquiera puede plantear preocupaciones o preguntas y juntos las abordamos.
Lo que alentamos
Para apoyar la arquitectura de nuestro sistema de equipos responsables y autónomos, he aquí las prácticas que animamos a todos los ingenieros a adoptar. Son importantes para nosotros y creemos que aportarán un valor añadido, pero también respetamos la autonomía de nuestros equipos e ingenieros y por ello, aunque creemos que son valiosas, permitimos cierta flexibilidad aquí en función del contexto en el que trabaje cada equipo.
Estamos a favor de las integraciones asincrónicas entre contextos delimitados. La comunicación asíncrona tiene algunas ventajas. En primer lugar, es más fácil empujarla a los límites de los sistemas de un contexto acotado. Un equipo puede crear oyentes que escuchen los mensajes publicados y almacenen los datos en su base de datos y que puedan estar completamente separados del resto de los sistemas del contexto acotado.
En segundo lugar, e igualmente importante, la comunicación asíncrona es más resistente.los equipos publican los datos a medida que cambian y esos datos se replican luego, mediante mensajes, a todos los contextos delimitados que los necesitan.y esto ocurre antes de que se necesiten los datos.cada contexto delimitado almacena los datos, como un caché local, en su propia base de datos. La gran ventaja aquí es que si una parte del sistema se cae, otras partes del sistema pueden continuar operando con sus datos en caché. Por supuesto, esto no funciona perfectamente, por lo que tratamos de crear una funcionalidad viable y degradada cuando una parte de nuestro sistema se cae y esto es mucho más fácil cuando ya tenemos un conjunto de datos en caché.
Por supuesto, hay casos en los que la comunicación asíncrona no es racional, como en el caso de los datos computarizados en tiempo real, que son muy pesados desde el punto de vista algorítmico, o casos en los que hay una tolerancia muy baja para una eventual consistencia.
Elegimos prácticas que se ajustan a nuestro equipo y al contexto del problema. Cada equipo y cada contexto delimitado que poseen son únicos; la arquitectura de nuestros sistemas para permitir la autonomía del equipo hace posible que los equipos elijan las prácticas que se ajustan a su situación única.Engineering @ añade como carril guía e incluye tanto las prácticas prescritas como las fomentadas, pero los equipos también pueden descubrir y crear en su propio equipo prácticas que son únicas para ellos.Esto es mucho más fácil porque nuestros sistemas y equipos están ligeramente acoplados.Hay muchas decisiones que los equipos tienen la libertad de elegir por sí mismos siempre que estén considerando responsablemente los impactos que sus decisiones tienen en todo el sistema y la organización.
Lo que evitamos
Hay una práctica que pedimos a los equipos que eviten para apoyar a los equipos responsables y autónomos. Tiene que ver con la forma en que compartimos los datos entre los equipos.
No compartimos los almacenes de datos entre contextos delimitados. Esta es una regla importante para la autonomía. Tan pronto como un equipo puede acceder a la base de datos de otro equipo, esa base de datos se vuelve más rígida e inalterable. Es importante que los equipos puedan moverse rápidamente dentro de su contexto delimitado y en cualquier lugar donde haya un acoplamiento, especialmente entre equipos, nos hace más lentos. Nuestros equipos saben que pueden cambiar libremente su base de datos, incluyendo la eliminación de columnas, el cambio de tipos de datos o la eliminación de tablas, siempre y cuando sus propios sistemas estén preparados para el cambio. No hay necesidad de consultar con otros equipos porque prohibimos estrictamente que los equipos toquen la base de datos de otro equipo.
Conclusión
El resultado final de todo esto es que tenemos más de 40 equipos que son capaces de trabajar de forma autónoma y de producir dentro de sus propios sistemas con una fricción mínima entre los equipos. Cuando un desarrollador llega al trabajo por la mañana, sabe que puede trabajar en una característica con su equipo y enviarla hasta la producción tan pronto como esté listo. Por supuesto, necesitamos colaborar con otros equipos porque todos estamos trabajando dentro del mismo sistema, pero el objetivo es minimizar, en la medida de lo posible, la rigidez y la fricción de los acoplamientos entre equipos.
Categorías: prácticasTags: agile, lean, values, architecture