feed.xml

<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="es-ES"><generator uri="https://jekyllrb.com/" version="4.2.0">Jekyll</generator><link href="/feed.xml" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" hreflang="es-ES" /><updated>2021-05-11T11:54:38+02:00</updated><id>/feed.xml</id><title type="html">VASS Engineering</title><subtitle>VASS Engineering</subtitle><entry><title type="html">ArchUnit</title><link href="/microservices/2021/04/06/article_archunit.html" rel="alternate" type="text/html" title="ArchUnit" /><published>2021-04-06T10:00:00+02:00</published><updated>2021-04-06T10:00:00+02:00</updated><id>/microservices/2021/04/06/article_archunit</id><content type="html" xml:base="/microservices/2021/04/06/article_archunit.html">&lt;h2 id=&quot;introducción&quot;&gt;Introducción&lt;/h2&gt;

&lt;p&gt;A la hora de abordar un nuevo proyecto, una vez que se ha decidido la arquitectura software más conveniente, puede que no todos los programadores la conozcan en detalle; si además el proyecto es complejo, pueden manifestarse dudas durante su desarrollo sobre si se ha infringido alguna convención al añadir un cambio.
&lt;!--more--&gt;
Si no hay ningún control, la deuda técnica aumentará por muy adecuado que fuera el planteamiento inicial, de este modo la arquitectura se terminará viendo comprometida y el mantenimiento será mucho más costoso.
Para evitar este problema lo ideal es establecer unas reglas o restricciones formales desde el principio, que se pueda disponer de ellas antes incluso de escribir la primera línea de código y sirvan además como respaldo ante cambios futuros. Siguiendo la misma idea que se aplica en TDD (desarrollo guiado por pruebas) pero a nivel de arquitectura en lugar de para con la funcionalidad (¡aunque ambos enfoques no son excluyentes!).
La biblioteca de ArchUnit es perfecta para este propósito.&lt;/p&gt;

&lt;h2 id=&quot;qué-es-archunit&quot;&gt;¿Qué es ArchUnit?&lt;/h2&gt;

&lt;p&gt;ArchUnit es una librería de código abierto gratuita escrita en Java de fácil integración en el marco de pruebas unitarias que permite verificar que el código se ajusta a la arquitectura acordada para un proyecto Java, es decir, posibilita implementar tests unitarios que prueben las dependencias entre clases, capas, organización de los paquetes, convenciones de codificación, etc.
Connatural a estos test se obtiene una forma de identificar las reglas de arquitectura utilizadas, facilitando la consolidación de la comprensión de la estructura del proyecto. Aportan valor como pruebas automáticas (de regresión) que pueden ser incluidas en un ciclo de integración continua verificando de forma desatendida (sin necesidad de auditorias o revisiones) la consistencia de la arquitectura permitiendo adelantar en una fase temprana del desarrollo cualquier problema que se detecte.&lt;/p&gt;

&lt;p&gt;La forma de incluir ArchUnit en los proyectos Java (Maven o gradle) es muy sencilla, solo hay que añadir la siguiente dependencia al pom.xml:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;    &amp;lt;dependency&amp;gt;
        &amp;lt;groupId&amp;gt;com.tngtech.archunit&amp;lt;/groupId&amp;gt;
        &amp;lt;artifactId&amp;gt;archunit&amp;lt;/artifactId&amp;gt;
        &amp;lt;version&amp;gt;0.18.0&amp;lt;/version&amp;gt;
        &amp;lt;scope&amp;gt;test&amp;lt;/scope&amp;gt;
    &amp;lt;/dependency&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;O en el build.gradle de gradle:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;    dependencies {
        testImplementation 'com.tngtech.archunit:archunit:0.16.0'
    }
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;ArchUnit utiliza reflexión y el análisis de bytecode de las clases compiladas para construir las reglas de arquitectura. Además, es muy versátil dado que ofrece varios niveles de abstracción que permiten extender o añadir nuevas reglas de manera sencilla e intuitiva. Estos niveles son los que siguen:&lt;/p&gt;

&lt;p&gt;⦁	&lt;em&gt;Core&lt;/em&gt;, que se ocupa de la infraestructura básica, es decir, cómo importar código de bytes en objetos Java.&lt;/p&gt;

&lt;p&gt;⦁	&lt;em&gt;Lang&lt;/em&gt;, contiene la sintaxis de reglas para especificar reglas de arquitectura.&lt;/p&gt;

&lt;p&gt;⦁	&lt;em&gt;Library&lt;/em&gt;, contiene reglas predefinidas más complejas.&lt;/p&gt;

&lt;p&gt;ArchUnit ofrece una Api para cada uno de ellos que detallamos a continuación.&lt;/p&gt;

&lt;h3 id=&quot;api&quot;&gt;Api&lt;/h3&gt;

&lt;p&gt;&lt;strong&gt;1.- Core&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Ofrece un mecanismo de importación de clases por defecto. Cada clase de pruebas puede definir el paquete de clases con el que trabajar, normalmente se hace referencia al paquete raíz de los archivos fuente del proyecto (clases). En este ejemplo sería  &lt;em&gt;org.tms&lt;/em&gt;&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;    import com.tngtech.archunit.core.domain.JavaClasses;
    import com.tngtech.archunit.core.importer.ClassFileImporter;
    import com.tngtech.archunit.core.importer.ImportOption;
    …
    JavaClasses classes = new ClassFileImporter()
    .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_TESTS)
    .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_ARCHIVES)
    .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_JARS)
    .importPackages(&quot;org.tms&quot;);
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Además, como se puede ver en el ejemplo es posible excluir mediante opciones de configuración la importación de archivos (no  &lt;em&gt;.java&lt;/em&gt;), clases de tests o  &lt;em&gt;JARs&lt;/em&gt;  para que no interfieran en las pruebas.&lt;/p&gt;

&lt;p&gt;Este es un uso común de la Api  &lt;em&gt;Core&lt;/em&gt;, pero cabe destacar que toda regla implementada utilizando la Api  &lt;em&gt;Lang&lt;/em&gt;  puede ser codificada solo utilizando esta api, ocurre que esto da lugar a reglas con un código muy extenso y muy difíciles de comprender (con una sintaxis muy parecida a la de  &lt;em&gt;java reflection&lt;/em&gt;). Con la api  &lt;em&gt;Library&lt;/em&gt;  ocurre lo mismo pero al revés, toda regla de  &lt;em&gt;Library&lt;/em&gt;  puede implementarse usando la Api  &lt;em&gt;Lang&lt;/em&gt; , pero estas son reglas predefinidas, varias de ellas transversales válidas para casi cualquier arquitectura que llevaría excesivo tiempo reescribir usando solo la Api  &lt;em&gt;Lang&lt;/em&gt;. Con todo, no es algo de lo que preocuparse, veremos que uso tiene cada una y como se combinan entre si (en particular, la referencia &lt;em&gt;classes&lt;/em&gt; del objeto de la clase &lt;em&gt;JavaClasses&lt;/em&gt; definido en el código de ejemplo será utilizada para aplicar las reglas definidas mediante las apis  &lt;em&gt;Lang&lt;/em&gt;  y  &lt;em&gt;Library&lt;/em&gt;  en los siguientes apartados).&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;2.- Lang&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Esta Api ofrece una potente sintaxis para expresar reglas de forma abstracta en un lenguaje natural fácilmente comprensible.&lt;/p&gt;

&lt;p&gt;Una regla (&lt;em&gt;ArchRule&lt;/em&gt;) tiene la siguiente estructura:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;ELEMENTS that PREDICATE should CONDITION
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;En la primera parte,  &lt;em&gt;ELEMENTS&lt;/em&gt; , se define que conjunto de elementos se pretenden evaluar, normalmente serán  &lt;em&gt;clases&lt;/em&gt;  o  &lt;em&gt;métodos&lt;/em&gt;  o  &lt;em&gt;ninguna clase&lt;/em&gt;  o  &lt;em&gt;ningún método&lt;/em&gt;  (pueden ser campos, constructores, bloques de código, etc). las referencias a estos elementos se encuentran en el paquete:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;com.tngtech.archunit.lang.syntax.ArchRuleDefinition
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;El predicado (o composición de predicados), &lt;em&gt;PREDICATE&lt;/em&gt;, hace referencia a las condiciones que cumplen los elementos, filtrando el conjunto anterior (los elementos que no cumplen el predicado, no se tienen en cuenta).&lt;/p&gt;

&lt;p&gt;&lt;em&gt;CONDITION&lt;/em&gt;, es la condición o condiciones que deben cumplir los elementos anteriores.&lt;/p&gt;

&lt;p&gt;Un ejemplo de implementación de una regla con esta Api sería el que sigue:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;    ArchRule rule = ArchRuleDefinition.classes().that().resideInAPackage(&quot;..service..&quot;)
	  .should().onlyBeAccessed().byAnyPackage(&quot;..controller..&quot;, &quot;..service..&quot;);
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;En este caso el elemento que queremos que se evalue serán las clases, el predicado indica que estas clases estarán ubicadas en el paquete ..service.. (incluyendo las clases en los subpaquetes) y la condición es que estas clases solo puedan ser accedidas por clases dentro del mismo paquete o del paquete ..controller…&lt;/p&gt;

&lt;p&gt;Nota: Las expresiones que definen las rutas de cada paquete siguen la sintaxis descrita en: https://www.javadoc.io/doc/com.tngtech.archunit/archunit/0.10.2/com/tngtech/archunit/base/PackageMatcher.html&lt;/p&gt;

&lt;p&gt;Para aplicar una regla a los elementos objeto del test (obtenidos mediante la Api Core) basta con llamar al método  &lt;em&gt;&lt;strong&gt;check(…)&lt;/strong&gt;&lt;/em&gt;  de  &lt;em&gt;ArchRule&lt;/em&gt; .&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;    rule.check(classes);
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Además, a la regla se le puede agregar en su construcción una llamada al método  &lt;em&gt;because(…)&lt;/em&gt;  , pasándole como argumento una cadena de texto donde se puede justificar el uso de la regla, esta es una opción interesante en general y para nuevos desarrolladores en particular dado que redunda en un mayor entendimiento de la arquitectura.&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;    ArchRule rule = ArchRuleDefinition.noClasses()
         .that().resideInAPackage(&quot;org.tms.domain..&quot;)
         .should().dependOnClassesThat()
         .resideInAnyPackage(&quot;org.tms.adapters..&quot;, &quot;org.tms.application..&quot;)
         .because(&quot;existiría un acoplamiento entre la capa de dominio y el resto&quot;);
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;En ulteriores ejemplos que se refieran a reglas, casi la totalidad involucraran esta Api dado que forma el grueso de la implementación de reglas de ArchUnit.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;3.- Library&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Este nivel ofrece una colección de reglas predefinidas. Es una Api más concisa para patrones más complejos, pero de uso común, abarca desde reglas para validar una arquitectura en capas, puertos y adaptadores (Onion) o verificaciones de ciclos entre segmentos a reglas propias de algunos frameworks como comprobar que la inyección de dependencias de  &lt;em&gt;Spring&lt;/em&gt;  no se hace a través de atributos de clase anotados con  &lt;em&gt;@Autowire&lt;/em&gt;  .&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;    Architectures.OnionArchitecture rule = onionArchitecture()
    .domainModels(DOMAIN_MODEL_PACKAGES)
    .domainServices(DOMAIN_SERVICE_PACKAGES)
    .applicationServices(APPLICATION_LAYER_PACKAGES)
    .adapter(&quot;adapter rest&quot;, REST_ADAPTERS_PACKAGES)
    .adapter(&quot;adapter persistence&quot;, PERSISTENCE_ADAPTERS_PACKAGES);

    ArchRule otherRule = GeneralCodingRules.NO_CLASSES_SHOULD_USE_FIELD_INJECTION;
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&quot;aspectos-a-cubrir-con-las-reglas-arquitectónicas&quot;&gt;Aspectos a cubrir con las reglas arquitectónicas&lt;/h3&gt;

&lt;p&gt;En lo que sigue se expodrán unos ejemplos práticos de la reglas utilizadas en un proyecto ficticio cuyo código fuente y tests pueden encontrase en el enlace al final de este artículo.&lt;/p&gt;

&lt;p&gt;Este proyecto es un ejemplo de aplicación siguiendo una arquitectura &lt;em&gt;Onion&lt;/em&gt; (refinamiento de la arquitectura de puertos-adaptadores) con algunos requisitos arquitectónicos añadidos para ilustrar posibles arquetipo de reglas definidas con ArchUnit. Su diagrama de componentes sería el siguiente:&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/img/archunit/diagram.png&quot; alt=&quot;components&quot; /&gt;&lt;/p&gt;

&lt;h3 id=&quot;convenciones-de-nomenclatura&quot;&gt;Convenciones de nomenclatura&lt;/h3&gt;
&lt;h4 id=&quot;paquetes-clases-métodos-etc&quot;&gt;(paquetes, clases, métodos, etc.)&lt;/h4&gt;

&lt;p&gt;Se puede establecer, por ejemplo, una regla para que toda clase con la anotación &lt;em&gt;@Configuration&lt;/em&gt; del framework de &lt;em&gt;Spring&lt;/em&gt; deba nombrarse con la terminación &lt;em&gt;…Configuration&lt;/em&gt; (y ubicarse en la capa de adaptadores):&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;    ArchRule rule = ArchRuleDefinition.classes()
    .that().areAnnotatedWith(Configuration.class)
    .should().haveSimpleNameEndingWith(&quot;Configuration&quot;)
    .andShould().resideInAnyPackage(&quot;org.tms.adapters..&quot;);
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&quot;convenciones-de-codificación&quot;&gt;Convenciones de codificación&lt;/h3&gt;
&lt;h4 id=&quot;atributos-métodos-modificadores-de-acceso-constructores-inicializadores-etc&quot;&gt;(atributos, métodos, modificadores de acceso, constructores, inicializadores, etc.)&lt;/h4&gt;

&lt;p&gt;Por ejemplo, se puede disponer una regla para que toda clase &lt;em&gt;Utils&lt;/em&gt; (normalmente contienen métodos públicos estáticos que no pueden encapsularse en un objeto, esto también se puede verificar implementando otras reglas que complementen la regla del ejemplo) debe tener un constructor privado para evitar su instanciación.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;    ArchRule rule = ArchRuleDefinition.constructors()
    .that().areDeclaredInClassesThat().haveSimpleNameEndingWith(&quot;Utils&quot;)
    .should().bePrivate();
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&quot;contenido&quot;&gt;Contenido&lt;/h3&gt;
&lt;h4 id=&quot;paquetes-clases-etc&quot;&gt;(paquetes, clases, etc.)&lt;/h4&gt;
&lt;p&gt;Se puede especificar una regla para que &lt;em&gt;ninguna&lt;/em&gt; clase definida con la notación &lt;em&gt;@Repository&lt;/em&gt; de &lt;em&gt;Spring&lt;/em&gt; pueda ubicarse fuera del paquete de persistencia de la capa de adaptadores, dado que estas clases dependen completamente del framework y la base de datos utilizada (en este caso MongoDB)&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;    ArchRule rule = ArchRuleDefinition.noClasses()
    .that().areAnnotatedWith(Repository.class)
    .should().resideOutsideOfPackage(&quot;org.tms.adapters.persistence..&quot;);
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&quot;dependencias--relaciones&quot;&gt;Dependencias / Relaciones&lt;/h3&gt;
&lt;h4 id=&quot;entre-capas-entre-paquetes-entre-clases-etc&quot;&gt;(entre capas, entre paquetes, entre clases, etc.)&lt;/h4&gt;
&lt;p&gt;Se puede hacer uso de la Api &lt;em&gt;Library&lt;/em&gt; para establecer que no pueda haber ninguna interdependencia entre adaptadores, por ejemplo entre el adaptador que permite la comunicación mediante una Api &lt;em&gt;rest&lt;/em&gt; y el adaptador para la persistencia en base de datos.
Se entiende por dependencia cualquier relación entre clases, ya sea de herencia, composición, uso de parámetros o tipo de retorno en los métodos, etc.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;    SliceRule rule = SlicesRuleDefinition.slices()
    .matching(&quot;org.tms.adapters.(*)&quot;)
    .should().notDependOnEachOther();
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&quot;dependencias-cíclicas-entre-capas&quot;&gt;Dependencias cíclicas entre capas&lt;/h3&gt;

&lt;p&gt;De manera análoga al anterior ejemplo, se puede generalizar la regla para que comprenda varios paquetes (o clases) como vértices formando grafos cerrados con sus dependencias como arístas.&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;    SliceRule rule = SlicesRuleDefinition.slices()
    .matching(&quot;org.tms.(*)..&quot;)
    .should().beFreeOfCycles();
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Nota:&lt;/strong&gt; Las regla para dependencias cíclicas puede ser configuradas para permitir un valor máximo de ciclos además de un número máximo de dependencias por ciclo. Es necesario incluir un fichero de propiedades (&lt;em&gt;archunit.properties&lt;/em&gt;) con estos valores (&lt;em&gt;cycles.maxNumberToDetect&lt;/em&gt; y &lt;em&gt;cycles.maxNumberOfDependenciesPerEdge&lt;/em&gt;) para que ArchUnit los reconozca.&lt;/p&gt;

&lt;h3 id=&quot;herencia&quot;&gt;Herencia&lt;/h3&gt;

&lt;p&gt;Se puede establecer que todo servicio de aplicación nombrado con la terminación &lt;em&gt;UseCase&lt;/em&gt; (de lo que se deduce que un servicio de aplicación debe cubrir un caso de uso) deba implementar la interfaz &lt;em&gt;CarSalesService&lt;/em&gt;.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;    ArchRule rule = ArchRuleDefinition.classes()
    .that().haveSimpleNameEndingWith(&quot;UseCase&quot;)
    .should().implement(CarSalesService.class);
    rule.check(classes);
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&quot;uso-de-anotaciones&quot;&gt;Uso de anotaciones&lt;/h3&gt;

&lt;p&gt;Por ejemplo que toda clase con terminación &lt;em&gt;Document&lt;/em&gt; que supone una referencia a una entidad de persistencia y deba utilizar la notación &lt;em&gt;@Document&lt;/em&gt; de &lt;em&gt;Spring Data JDBC&lt;/em&gt;, asimismo que deba estar ubicada dentro del adaptador de persistencia.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;    ArchRule rule = ArchRuleDefinition.classes()
    .that().haveSimpleNameEndingWith(&quot;Document&quot;)
    .should().beAnnotatedWith(Document.class).andShould().resideOutsideOfPackage(&quot;org.tms.adapters.persistence..&quot;);
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&quot;restricciones&quot;&gt;Restricciones&lt;/h3&gt;

&lt;p&gt;La siguiente regla utiliza la Api &lt;em&gt;Library&lt;/em&gt; nuevamente para chequear que no se lanza ninguna excepción genérica en ningún método de ninguna clase.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;    ArchRule rule = ArchRuleDefinition.noClasses()
    .should(GeneralCodingRules.THROW_GENERIC_EXCEPTIONS);
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&quot;personalización&quot;&gt;Personalización&lt;/h3&gt;

&lt;p&gt;ArchUnit ofrece una Api muy completa, es difícil que haya una regla que no pueda ser expresada mediante la sintaxis de la Api Lang, pero con todo si esto ocurre, ArchUnit  permite su extensión de manera rápida y sencilla implementado el método abstracto check de la clase ArchCondition o apply de DescribedPredicate. Por ejemplo:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;ArchRule rule = ArchRuleDefinition.noMethods().should(haveMoreThanSixParameters());
...
public ArchCondition&amp;lt;JavaMethod&amp;gt; haveMoreThanSixParameters() {
    return new ArchCondition&amp;lt;&amp;gt;(&quot;have more than six parameters&quot;) {
        @Override
        public void check(JavaMethod javaMethod, ConditionEvents conditionEvents) {
            boolean satisfied = javaMethod.reflect().getParameterCount() &amp;gt; 6;
            conditionEvents.add(new SimpleConditionEvent(javaMethod, satisfied,
            String.format(&quot;method %s from class %s has %s than '%s' parameters&quot;, 
				javaMethod.getName(), javaMethod.getOwner().getName(),
				satisfied ? &quot;more&quot; : &quot;minus (or equals to)&quot;, &quot;six&quot;)));
        }
    }
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Establecemos una &lt;em&gt;archCondition&lt;/em&gt; personalizada instanciada para el tipo específico JavaMethod (del Core de ArchUnit), de manera que se cuente los parámetros de cada método y evalue que no supere 6 argumentos.&lt;/p&gt;

&lt;p&gt;Las reglas para arquitecturas en capas particulares también pueden ser definidas mediante la Api  &lt;em&gt;Library&lt;/em&gt;  , siempre y cuando estén basadas en capas (si no habría que utilizar las otras Apis):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;    private static Architectures.LayeredArchitecture portsAndAdaptersArchitecture = Architectures
        .layeredArchitecture()
        .layer(&quot;domain layer&quot;).definedBy(&quot;org.tms.domain..&quot;)
        .layer(&quot;application layer&quot;).definedBy(&quot;org.tms.application..&quot;)
        .layer(&quot;adapter layer&quot;).definedBy(&quot;org.tms.adapters..&quot;);

    ArchRule rule = portsAndAdaptersArchitecture.whereLayer(&quot;domain layer&quot;)
            .mayOnlyBeAccessedByLayers(&quot;application layer&quot;);
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&quot;integración-con-plantuml&quot;&gt;Integración con plantUml&lt;/h3&gt;

&lt;p&gt;ArchUnit permite la integración con diagramas de componentes desarrollados con  &lt;em&gt;PlantUML&lt;/em&gt;  , simplificando (aún más si cabe) la construcción de las reglas de validación de las relaciones entre componentes, de manera que no haya que escribir varías reglas para asegurarse de que la codificación sigue el diagrama planteado.
En este ejemplo se ha importado el diagrama mostrado al principio de este artículo y se ha establecido que se consideren solo las dependencias descritas en él (no se tienen en cuenta relaciones implícitas propias de Java, como que toda clase hereda de la clase Object).&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;    ArchRule rule = ArchRuleDefinition.classes().should(
    PlantUmlArchCondition.adhereToPlantUmlDiagram(this.getClass().getResource(&quot;template_archunit.puml&quot;),
    PlantUmlArchCondition.Configurations.consideringOnlyDependenciesInDiagram()));
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&quot;errores&quot;&gt;Errores&lt;/h3&gt;

&lt;p&gt;Cuando se incumple una regla en un test, ArchUnit muestra un mensaje detallado de la infracción, indicando el número de veces que se ha infringido la regla, así como las clases implicadas, por ejemplo (utilizando el test de dependencias cíclicas entre capas):&lt;/p&gt;

&lt;h1&gt;&lt;img src=&quot;/assets/img/archunit/diagram2.png&quot; alt=&quot;alt text&quot; /&gt;&lt;/h1&gt;
&lt;pre&gt;&lt;code&gt;@Test
public void layersShouldBeFreeOfCycles() {
    SliceRule rule = SlicesRuleDefinition.slices()
    .matching(&quot;org.tms.(*)..&quot;)
    .should().beFreeOfCycles();
    rule.check(classes);
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;em&gt;java.lang.AssertionError: Architecture Violation [Priority: MEDIUM] - Rule ‘slices matching ‘org.tms.(*)..’ should be free of cycles’ was violated (1 times):
Cycle detected: &lt;strong&gt;Slice adapters -&amp;gt; Slice application -&amp;gt; Slice adapters&lt;/strong&gt;
Dependencies of Slice adapters
Class &amp;lt;org.tms.&lt;strong&gt;adapters.persistence&lt;/strong&gt;.CarSalesAdapterRepository&amp;gt; implements interface &amp;lt;org.tms.&lt;strong&gt;application.ports&lt;/strong&gt;.CarSalesPort&amp;gt;
…
Dependencies of Slice application
Field &amp;lt;org.tms.&lt;strong&gt;application.services&lt;/strong&gt;.RegisterCarUseCase.r&amp;gt; has type &amp;lt;org.tms.&lt;strong&gt;adapters.persistence&lt;/strong&gt;.CarSalesDelegatedRepository&amp;gt; in (RegisterCarUseCase.java:0)&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;En este caso ArchUnit ha revelado que además de una relación entre la capa de adaptadores y aplicación existe otra clase de la capa de aplicación que depende de una clase de la capa de adaptadores.&lt;/p&gt;

&lt;h3 id=&quot;código-legacy&quot;&gt;Código legacy&lt;/h3&gt;

&lt;p&gt;En proyectos legacy también podemos integrar ArchUnit. En estos casos es habitual encontrar que el código provoque multitud de infracciones que se tengan que una corrección no trivial que deba postergarse.&lt;/p&gt;

&lt;p&gt;Este código deberá estar cubierto por pruebas de arquitectura que garanticen que al menos no aumenten las transgresiones ya existentes.&lt;/p&gt;

&lt;p&gt;Lo que haremos será ignorar las infracciones actuales basadas en coincidencias de expresiones regulares simples.
Para ello, incluiremos un archivo con el nombre &lt;em&gt;archunit_ignore_patterns.txt&lt;/em&gt; en la carpeta de recursos del proyecto.&lt;/p&gt;

&lt;p&gt;Por ejemplo, imaginemos que la clase  &lt;em&gt;org.tms.LegacyService&lt;/em&gt;  o  &lt;em&gt;org.tms.adapters.persistence.LegacyCarSalesRepository&lt;/em&gt;  tienen muchas infracciones. Cubrimos estas clases agregando al archivo archunit_ignore_patterns.txt la siguiente linea:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;.*Legacy*.*
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Esta línea se interpretará como una expresión regular y se comparará con las infracciones notificadas. Se ignorarán las infracciones con un mensaje que coincida con el patrón.&lt;/p&gt;

&lt;p&gt;Como se ha comentado anteriormente, podemos encontrarnos con proyectos que tengan un número demasiado elevado de infracciones como para corregirlas en el momento de detectarse.
Una forma de abordar este problema es establecer un enfoque iterativo, que evite que la base del código se deteriore más.
Para ello nos podemos apoyar en  &lt;em&gt;FreezingArchRule&lt;/em&gt;  . Estas reglas permiten registrar las infracciones en fichero interno &lt;em&gt;ViolationStore&lt;/em&gt;  .
Al istanciar una  &lt;em&gt;ArchRule&lt;/em&gt;  y aplicar FreezingArchRule.freeze(archRule), podemos registrar todas las infracciones actuales y evitar que se agreguen nuevas.
Esto permite ignorar una regla la primera vez que se ejecuta y mientras no se resuelva la infracción, es decir, una vez resuelta, la regla no volverá a ignorarse.&lt;/p&gt;

&lt;p&gt;Para aplicarse requiere que el fichero  &lt;em&gt;archunit.properties&lt;/em&gt;  tenga las propiedades:&lt;/p&gt;

&lt;p&gt;freeze.store.default.allowStoreCreation=true
(por defecto es false)
freeze.store.default.allowStoreUpdate=false
(por defecto es true)&lt;/p&gt;

&lt;p&gt;Por defecto, FreezingArchRulese utiliza un  &lt;em&gt;ViolationStore&lt;/em&gt;  simple basado en texto sin formato.
Esto es suficiente para agregar estos archivos a cualquier sistema de control de versiones para realizar un seguimiento continuo del progreso.
Se puede configurar la ubicación de  &lt;em&gt;ViolationStore&lt;/em&gt;  en  &lt;em&gt;archunit.properties&lt;/em&gt;:&lt;/p&gt;

&lt;p&gt;&lt;em&gt;freeze.store.default.path=/….&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Ejemplo de cómo quedarían las reglas:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;    FreezingArchRule freezeRule = FreezingArchRule.freeze(ArchRuleDefinition.classes()
    .that().resideInAPackage(&quot;org.tms.domain..&quot;)
    .should().onlyBeAccessed().byAnyPackage(&quot;org.tms.domain..&quot;, &quot;org.tms.application..&quot;));
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id=&quot;conclusiones&quot;&gt;Conclusiones&lt;/h2&gt;

&lt;p&gt;ArchUnit ofrece una poderosa herramienta para mantener la validez de los requisitos arquitectónicos de cualquier proyecto java durante todo su ciclo de vida. Fomenta el uso de buenas prácticas acordes a las arquitecturas propuestas y ayuda a entender las mismas mediante la definición de reglas fácilmente expresables. Estas reglas hacen un tratamiento homogéneo de cualquier aspecto relacionado con la arquitectura.&lt;/p&gt;

&lt;p&gt;Su integración en los proyectos ya sean nuevos o heredados es muy fácil y permite estandarizar un conjunto de tests favoreciendo la normalización de las arquitecturas.
También su curva de aprendizaje es mínima, basta con codificar un test y el paradigma se asume rápidamente.&lt;/p&gt;

&lt;p&gt;No hemos encontrado ninguna razón para no usarlo, al menos… ¡no la hay para no probarlo!&lt;/p&gt;

&lt;h2 id=&quot;código-fuente&quot;&gt;Código fuente&lt;/h2&gt;

&lt;p&gt;https://github.com/FabianSR/archunit-example-template&lt;/p&gt;</content><author><name>Fabian Sanchez, Javier Escalada</name></author><category term="Microservices" /><summary type="html">Introducción A la hora de abordar un nuevo proyecto, una vez que se ha decidido la arquitectura software más conveniente, puede que no todos los programadores la conozcan en detalle; si además el proyecto es complejo, pueden manifestarse dudas durante su desarrollo sobre si se ha infringido alguna convención al añadir un cambio.</summary></entry></feed>