Class Architectures

java.lang.Object
com.tngtech.archunit.library.Architectures

@PublicAPI(usage=ACCESS) public final class Architectures extends Object
Offers convenience to assert typical architectures:
  • Method Details

    • layeredArchitecture

      Can be used to assert a typical layered architecture, e.g. with a UI layer, a business logic layer and a persistence layer, where specific access rules should be adhered to, like UI may not access persistence and each layer may only access lower layers, i.e. UI → business logic → persistence.

      A layered architecture can for example be defined like this:
      layeredArchitecture()
       .consideringAllDependencies()
       .layer("UI").definedBy("my.application.ui..")
       .layer("Business Logic").definedBy("my.application.domain..")
       .layer("Persistence").definedBy("my.application.persistence..")
      
       .whereLayer("UI").mayNotBeAccessedByAnyLayer()
       .whereLayer("Business Logic").mayOnlyBeAccessedByLayers("UI")
       .whereLayer("Persistence").mayOnlyBeAccessedByLayers("Business Logic")
       
      NOTE: Principally it would be possible to assert such an architecture in a white list or black list way.
      I.e. one can specify layer 'Persistence' MAY ONLY be accessed by layer 'Business Logic' (white list), or layer 'Persistence' MAY NOT access layer 'Business Logic' AND MAY NOT access layer 'UI' (black list).
      LayeredArchitecture only supports the white list way, because it prevents detours "outside of the architecture", e.g.
      'Persistence' → 'my.application.somehelper' → 'Business Logic'
      The white list way enforces that every class that wants to interact with classes inside of the layered architecture must be part of the layered architecture itself and thus adhere to the same rules.
      Returns:
      An ArchRule enforcing the specified layered architecture
    • onionArchitecture

      @PublicAPI(usage=ACCESS) public static Architectures.OnionArchitecture onionArchitecture()