Si ha leído o conoce el libro ‘Patrones de arquitectura de aplicaciones empresariales de Martin Fowler, 2002’, ¿qué tan relevante es el contenido hoy?

Answer 1

El contenido sigue siendo relevante. Quizás más que nunca. Particularmente si estás involucrado con sistemas de representación. Los principios básicos no cambian realmente. Otros simplemente los toman, los hacen más complejos, agregan capas de abstracción, los llaman con un nuevo nombre y fingen que son algo nuevo. O eso, o simplemente descartar cualquiera de esos principios básicos “antiguos” e “inconvenientes” en nombre de “ágil de prueba”.

Fowler describe el uso de un modelo de dominio de objetos para dominios grandes y complejos (y también para los más simples). Ese enfoque no está en uso generalizado hoy. No porque no sea aplicable, sino porque el modelado de datos como paradigma de diseño está mucho más extendido. La M en MVC está firmemente establecida hoy en el sentido de “modelo de datos”. Un modelo de datos impulsado en gran medida por código de procedimiento impulsado por casos de uso [1] y organizado mediante descomposición funcional en una capa de aplicación / servicio. Uno lleno de cosas llamado gerente, coordinadores, servicios, controladores y controladores, y exhibiendo los mismos problemas que pensamos que aprendimos a superar en nuestra búsqueda de no producir una gran bola de lodo.

La última respuesta a eso, por supuesto, es crear la funcionalidad como aplicaciones separadas detrás de un límite de red, también conocido como microservicios. Al menos tenemos bolas de barro más pequeñas y el sueño de un devop.

Lo que también ha cambiado es que los problemas orientados a la informática se han vuelto cada vez más importantes debido a los grandes datos, el gran análisis y la gran infraestructura. Parece que Dijkstra finalmente ganó, porque para muchos hoy, toda la informática es solo el procesamiento de datos, con énfasis en las estructuras de datos y algoritmos. En ese contexto, los Patrones de Arquitectura de Aplicación Empresarial deben parecer texto obsoleto antiguo y obtuso

---

[1] usan casos o historias que sufren la necesidad constante de descomponerlos aún más a medida que cambian los requisitos y se descubren.

Answer 2

Sigue siendo extremadamente relevante!

Solo por claridad, y esto puede ser algo controvertido para otros EA y arquitectos de aplicaciones, pero los patrones dentro de PoEAA también son relevantes en más roles de arquitectura de soluciones y arquitectura de negocios (lo sé, ¿WTF, verdad?).

El problema que tiene PoEAA es que la gran mayoría de los arquitectos de aplicaciones no tocaron este libro. Muy pocos de sus patrones lo han convertido en un uso generalizado (aunque plataformas como FuseESB / ServiceMix hacen prácticamente todos ellos: Oracle Fusion, TibcoAE, NeuronESB y algunos otros, no implementan ni la mitad de ellos. de otra manera y podemos dejar de hablar sobre ese mestizo BizTalk por completo.

Algunos patrones se usan en exceso de manera desproporcionada (como Message Bus, Message Queue, Sync-Async, Message Box, Brokers, Proxies, split-aggregator, CDM, etc.) especialmente por proveedores que compilan productos que cubren uno o dos de estos (como Enterprise Buses de servicio: aunque los ESB son útiles, no siempre son la mejor herramienta para el trabajo, dependiendo del nivel de integración requerido).

Esto deja a la gente en una posición realmente extraña donde el resto del libro también se pierde para ellos, ya que, como muchos de los libros de Fowler, también introduce a la gente a algunos de los pensamientos detrás de los patrones, que es clave aquí, y hay un dicho Yo uso mucho

“El software no resolverá problemas en tu pensamiento / cabeza”

¿Qué quiero decir con eso? Sencillo. Piensa mal (o no pienses en absoluto) y la plataforma que construyas será basura. Lo más probable es que sean subóptimos y contengan antipatrones importantes, lo que le causará problemas en el futuro. Obtenga un antipatrón arquitectónico y tendrá grandes problemas.

Aquí hay un ejemplo …

ESB

Este es un caso de uso que veo a menudo. Empresas que toman decisiones sobre servicios de infraestructura, específicamente Buses de servicios empresariales (ESB) demasiado pronto.

Piden a los desarrolladores y al departamento de TI que creen servicios para conectarse al ESB desde el día 1, sin siquiera saber si el ESB es:

1. Necesario y cuál se adaptaría mejor a la empresa (¡nunca compre a vendedores!)
2. Suficiente para implementar la necesidad comercial: tenga en cuenta que este es un problema detallado de mapeo de soluciones. A veces no tienes ese conocimiento por adelantado.
3. Va a posicionarse en un contexto apropiado.

Tomando el diagrama, imagine una situación en la que se compra un ESB y se dicta un mandato para integrarlo, muchos de los cuales requieren varios millones en licencias, consultoría, desarrollo e integración. En el desarrollo de la izquierda, el servicio está vinculado al ESB, lo que significa que la empresa debe emplear habilidades de ESB, habilidades de arquitectura de datos (para el modelo canónico), configuración y enrutamiento, así como habilidades de desarrollo de software en el servicio de consumo o publicación. información del contrato. Una amplia base de habilidades y todo cuesta.

Además, mirando el número de partes móviles en el primer contexto. Hay 10 partes móviles dentro del proceso que transforman las solicitudes de servicio en respuestas y viceversa (nota, no hay colas de mensajes aquí). Esto está en marcado contraste con el diseño de la derecha que hace lo mismo y lo hace con solo dos partes móviles. Más cosas pueden salir mal en el lado izquierdo sobre el derecho. La probabilidad de que todos trabajen dada la misma pila de tecnología es menor. No puede mejorar la probabilidad de tiempo de actividad agregando algo en serie. Eso es imposible.

También hay un punto de cruce cuando un ESB se convierte en una buena idea sobre conexiones directas o incluso microservicios. Este conjunto fundamental de matemáticas no está incluido en el libro, pero tampoco está disponible en muchos medios convencionales (lo viste aquí primero). Es esto.

Donde la barra H y la barra C son números máximos de ambos canales de comunicación y conexiones. La clave para esto es tener en cuenta que a medida que crece el número de servicios, las adiciones lineales al ESB eventualmente “superan” la cantidad y el esfuerzo para el número total de conexiones de servicio directas, punto a punto y de manera similar cualquier “árbol de dependencia” construido a través de Los microservicios también sufrirán un problema similar, pero no tan catastrófico (podría decirse que debería rediseñar sus microservicios en ese momento, pero estoy divagando) y esto es un caso simple. El problema es que, como hemos visto, la cantidad de partes móviles es mayor que la directa para una conexión punto a punto. Esto significa que las adiciones lineales son al menos 4 por servicio, lo que también afecta la probabilidad y la ubicación del punto de cruce entre los dos estilos de arquitectura. Si coloca colas entre el ESB y los servicios de extremo a extremo, esto también cambia la ubicación del crossover de disponibilidad.

Resumen

Entonces, sí, después de esa excursión, sigue siendo relevante, pero comprende los fundamentos de todos los esfuerzos de ingeniería arquitectónica en todos los dominios (esfuerzo por cambiar y agregar, efecto sobre la disponibilidad, rendimiento, etc.) y, de manera crucial, comprende las compensaciones que estás haciendo.

Answer 3

“Los conceptos nunca cambian, evolucionan, sin embargo, el enfoque para implementar los conceptos sí cambia”

Este es sin duda uno de los mejores libros disponibles hasta ahora. Excelente para comprender cómo se puede pensar la pila de aplicaciones empresariales de principio a fin. En lugar de aprenderlo de la manera difícil, intente comprender cómo se mezclan las cosas entre sí. También explica sobre la estrategia de distribución y la base táctil sobre aspectos importantes de los patrones de arquitectura de extremo a extremo y el diseño de aplicaciones con las opciones de lenguaje. La arquitectura tiene que ver con su visión, así que conciba el diseño y haga espacio para escalar en el futuro mientras satisface la demanda actual.

Léalo, ingiéralo y aplíquelo si cree que está trabajando en su diseño. Algunas de las buenas lecturas: Eclosión de patrones: patrones de diseño aplicados

Answer 4

Este libro es una excelente referencia. A pesar de lo que pueda leer en la jerga impulsada por el marketing que inunda todo el espacio de datos, hay pocas novedades bajo el sol. Lo que ES nuevo o al menos inusual es que las personas puedan sintetizar lo que existe en soluciones prácticas y sostenibles.

Lea y estudie Fowler para las filosofías de diseño orientado a objetos y luego siga el rastro de su curiosidad. No crea en una sola fuente (a menos que, por supuesto, esa fuente sea yo 🙂) y trate de comprender estos temas en lugar de solo adquirir información y datos.

Answer 5

El vocabulario que presenta el libro todavía está en uso hoy.

Para empezar, tenga en cuenta que hay dos significados de “Arquitectura de aplicación”:

1. Definición de la arquitectura de una aplicación individual
2. Definición de aplicaciones empleadas por la TI empresarial (como cajas negras)

El libro se centra en “1”. Si te ves como un arquitecto de aplicaciones empresariales, no sería tan útil para ti.

Sin embargo, si se ve a sí mismo como un líder técnico en el desarrollo de un sistema de negocios en una tienda de TI empresarial, como una gran atracción de una consultoría que brinda docenas de codificadores mediocres ridículamente caros, o para un proveedor, lo más probable es que el proyecto use la combinación de tecnología asumida por el libro.

La nueva forma de hacer las cosas probablemente involucrará microservicios, que podrían implementarse utilizando tecnologías que hacen innecesarios los patrones de Fowler. Sin embargo, pasaría un tiempo hasta que los microservicios lleguen a la superficie de la TI.