Repasando los clásicos: «Patterns of Enterpise Application Architecture» de Martin Fowler

Cuando se trata de aplicaciones empresariales, se hacen necesarios otro tipo de patrones que afectan más a la arquitectura que al desarrollo. Y este libro va de esos patrones o “buenas prácticas” a nivel de arquitectura.

Seguramente ya conozcas los patrones de diseño o te hayas pegado con alguno. El concepto es muy sencillo: soluciones probadas aplicadas a problemas recurrentes. Pero por lo general son soluciones locales que ni implican más allá de 2 o 3 clases que resuelven problemas concretos en el desarrollo (vale, hay algunos patrones que condicionan toda la arquitectura). Pero cuando se trata de aplicaciones «grandes», y con grandes quiero decir, aplicaciones «empresariales», se hacen necesarios otro tipo de patrones que afectan más a la arquitectura que al desarrollo. Y este libro va de esos patrones o «buenas prácticas» a nivel de arquitectura.

Los libros de patrones son siempre una gran oportunidad para ver cómo trabajan otros desarrolladores. A estas alturas no creo que tenga que explicarte que el autor de este libro, Martin Fowler, es uno de los desarrolladores más relevantes y reconocido por su experiencia y calidad de divulgaciones (como este libro), así que cuando vi este libro no dudé en conseguirlo.

Como otros libros de esta temática, la estructura no puede ser más sencilla: se trata de una enumeración patrón por patrón, en cada uno de los cuales se presenta una introducción que justifica su uso y una explicación del desarrollo, acompañada de código en un lenguaje conocido, en este caso Java y C# (.NET). Esta definición de patrones conforma la segunda y más extensa parte del libro (páginas 107-510), dejando para la primera parte una buena introducción sobre aspecto generales de la arquitectura.

Efectivamente, las 100 primeras páginas del libro tratan sobre consideraciones sobre diferentes temas de arquitectura que hay que tener en cuenta a la hora de desarrollar un proyecto. Me parece la parte más relevante del libro y que más aporta a un lector a día de hoy (luego explicaré el porqué la segunda parte lo es menos), sobre todo teniendo en cuenta de que le sirven como excusa para ir introduciendo patrones concretos que se tratarán en la segunda parte. Como en otros libros de Fowler como el de refactoring, cada patrón está perfectamente numerado para ser localizado rápidamente por número de página de aparición.

En esta primera parte se tratan temas como:

• La división en capas de la arqutiectura: las clásicas tres capas y cómo distribuirlas.
• La lógica del dominio del problema: introduciendo conceptos del tan de moda hoy «Domain Driven Design«.
• Relación de la arquitectura con bases de datos (relacionales en aquella época).
• La capa Web de presentación con trazos de MVC aunque bastante desfasado en las tiempos actuales.
• La problemática de la concurrencia: ACID, niveles de aislamiento, transaccionalidad…
• La sesión y la importancia de lograr servicios sin sesión.
• Estrategias de distribución de módulos en los entornos físicos.

Aunque son temas bien tratados y escritos, no obstante, y es la grandísima «contra» de este libro, hay que ubicarlos en otra época. Y es que en el mundo del desarrollo los años no perdonan, y este libro ya cuenta con 13 años a sus espaldas desde su primera edición. A medida que uno lee las valiosas cuestiones que trata, le vienen a la cabeza soluciones existentes hoy en día que minimizan los problemas (aunque en algunos casos han cambiado de dimensión).

Hay algunas cuestiones que son universales y tienen un tratamiento valioso en el libro, con independencia del statu quo en el momento de su aplicación: sesiones sin estado, la importancia del dominio, el acceso a bases de datos relacionales o ciertas partes de la concurrencia. Pero hay otras que han cambiado demasiado y no son consejos tan útiles: ya podrás imaginar las diferentes en la capa de distribución Web que existen actualmente (frameworks MVC en JS + REST) con las que habia en 2002-03 (JSP o algún template rudimentario); o la forma de distribuir aplicaciones con el uso de máquinas virtuales, la nube o los contenedores como Docker…

Respecto a la segunda y más extensa parte del libro, se trata de una exposición de patrones que Martin Fowler y otros colaboradores se han encontrado a lo largo de su experiencia como consultores de arquitectura de software. Muchos de estos patrones a día de hoy ya forman parte de la jerga habitual de la profesión o se han ido desarrollando dentro de frameworks hasta que se han convertido en un estándar. Algunos de ellos puede que te resulten más exóticos, mientras que los más conocidos supone una forma estupenda para volver a conocerlos desde un punto de vista más formal.

Los Patrones de arquitectura expuestos se agrupan en torno a diferentes temáticas, por citar algunas:

• Domain Logic Patterns: como el Domain Model para establecer un buen dominio basado en clases del problema en su capa, o Table Module para que sea el diseño de base de datos el que organice el dominio, o Service Layer a modo de wrapper de una arquitectura completa.
• Data Source: para el acceso a fuentes de datos y su relación con un dominio basado en programación orientada a objetos: Data Mapper para las operaciones de un objeto de dominio en su tabla de base de datos por ejemplo (a lo MyBatis).
• Object-Relational Structural: que tratan de la relación entre el modelo en una base de datos relacional y el modelo orientado a objetos. Ejemplos son: el mapeo de foreign keys, tratamiento de asociaciones o herencias, etcétera.
• Web presentation: como el conocido MVC de separación de responsabilidades, plantillas con Template View, el Application Controller.
• Distribution: como los Data Transfer Object (DTO) como POJO para la comunicación entre capas.
  – Offline Concurrency como los diferentes tipos de «lock»: optimistic, pessimistic, coarse o implicit lock.
• Session State: Client / Server / Database session state, para diferentes estrategias de almacenamiento de la sesión en servidores.
• Base: Gateway para el aislamiento de otros subsistemas; Record Set para el acceso al resultado de una query; Value Object o Plugin.

No he citado todos aunque algunos que son representativos. Tienes el catálogo completo con una breve explicación de cada uno en la propia página de Martin Fowler: http://martinfowler.com/eaaCatalog/. Como podrás ver muchos de ellos te serán de sobra conocidos, o al menos los habrás utilizado y leído su nombre, por lo que siempre es interesante leer de un autor de esta importancia el motivo de su existencia y quizá aprendas otros posibles escenarios de uso que no te habías planteado hasta ahora.

Cada uno de los patrones está acompañado de un minucioso análisis introductorio y de desarrollo, aunque a veces realmente excesivo, justificando la utilidad del patrón, así como una pequeña implementación en código .NET o Java para dotar de mayor precisión a la explicación.

En resumen, se trata de otro de los libros clásicos sobre el desarrollo de software cuyo éxito ha sido fundirse dentro de las buenas prácticas de esta profesión, pero que ya por sí solo no representan grandes novedades. Antes de adquirirlo te recomiendo que visites la página que Martin Fowler tiene dedicada a estos patrones: Puedes consultar los patrones que se exponen en este libro en la propia página de Martin Fowler. Si encuentras algunos de ellos interesantes, puedes ampliar con las exhaustivas indicaciones que hay en el libro, pero si no ves ninguna novedad, mejor invierte tu tiempo (y dinero) en algo más puntero.

Si te pica la curiosidad y quieres añadir otro clásico de la literatura de desarrollo de software a tu biblioteca, puedes adquirirlo en Amazon.es a través de este link:

Cómpralo en Amazon