JAX 08: 5 Regeln für eine bessere Architektur (Update)

von Thomas Bahn,
assono GmbH, Standort Kiel,



Alexander von Zitzewitz
5 Regeln für eine bessere Architektur

Your most frightening enemy: the Dragon of Complexity

Erosion of Architecture - Dragon Fire
Architecture erosion is quite a known problem

  • System knowledge and skills are not evenly distributed
  • coupling and complexity grows faster than system size. When you realize it, it is often too late.
  • Unwanted dependencies are created without being noticed.
  • Management usually doesn't care about internal quality (black box)
  • Time pressure is always a good excuse to sacrifice structure

Typical symptoms of an eroded architecture
are a high degree of coupling and a lot of cyclic dependencies

  • Changes become increasingly difficult
  • Testing and code comprehension also become increasingly difficult
  • Deployment problems of all kind

Resistance to Change vs. time:
exponential ascent
do architecture management: higher cost in the beginning, big rewards over time


Architecture Management - Fighting the Dragon

Goal 1: Keep a simple and maintainable software structure

  • use an architecture meta model
  • define a mapping from your code to the architecture (naming conventions help)
  • make sure the architecture is always matched by the code
  • avoid cyclic dependencies
  • controls and minimize overall coupling

    Goal 2: Keep complexity under control
  • avoid monster Java files
  • avoid overly long or complex methods (cyclomatic complexity check)
  • avoid monster packages

    Benefits: Dramatic reduction of overall project cost
  • improved testability
  • improved code readability
  • improved modularity
  • code can be extended and maintained much easier


    A Proven Architecture Meta Model

    1. Step: Cut horizontally into Layers
    User interfaces
    Business logic
    Data Access

    2. Step: Cut vertically into vertical slices by functional aspects
    Contracts
    Customer
    User
    Common

    3. Step: Defines the rules of engagement
    Matrix layer x slices: which block = subsystems depend on which others?


    Mapping of Your Code to the Meta Model

    Each package is mapped to exactly one subsystem
    If packages contain types of several subsystems, virtual refactorings are helpful
    A good naming convention for packages can make your life very simple
  • e. g. com.hello2morrow.project.verticalslice.layer...
    Subsystems should have interfaces
    Work incrementally
  • start with your layering
  • then add the vertical slices (if applicable)
  • define subsystem interfaces
  • fine tune the rules of engagement on the subsystem level


    How to measure coupling

    ACD = Average Component Dependency
    Average number of direct and indirect dependencies
    rACD = ACD / number of elements (--> it's always between 0 and 1)
    NCCD is even more useful (normalized components coupling dependency; comparison to balanced binary tree)

    use Dependency Inversion to reduce coupling

    the bigger the system, the smaller the rACD should be

    e. g. 500 elements, rACD < 7% might be good
    NCCD < 6 might be good (independent from system's size!)


    How to keep the coupling low?

    Dependency Inversion Principle (Robert C. Martin)
  • build on abstractions, not on implementations
  • best pattern for a flexible architecture with low coupling
  • have a look at dependency injection frameworks (e. g. Spring)


    Golden Rules for a successful project

    Rule 1: Define a cycle free logical architecture down to the level of subsystems and a strict and consistent package naming convention

    Rule 2: Do not allow cyclic dependencies between different packages

    Rule 3: Keep the coupling low (NCCD < 6)

    Rule 4: Limit the size of Java files (700 LOC is a reasonable value)

    Rule 5: Limit the cyclomatic complexity of methods (e. g. 15)

    Rule 6: Limit the size of a package (e. g. < 50 types)


    Update:
    Removed German umlaut from URL
Veranstaltung Fachbeitrag JavaScript Java Sonstiges

Sie haben Fragen zu diesem Artikel? Kontaktieren Sie uns gerne: blog@assono.de

Sie wollen eine individuelle Lösung? Kontaktieren Sie uns

Weitere interessante Artikel

Sie haben Fragen oder möchten eine Demo anfordern?

Wenn Sie mehr über unsere Angebote erfahren möchten, können Sie uns jederzeit kontaktieren. Gerne erstellen wir eine individuelle Demo für Sie.

Wir verwenden Ihre Daten, um Sie einmalig per E-Mail zu kontaktieren. Wir geben Ihre Daten nicht an Dritte weiter. Siehe: Datenschutzhinweise
assono GmbH

Standort Kiel (Zentrale)
assono GmbH
Lise-Meitner-Straße 1–7
24223 Schwentinental

Standort Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Telefonnummern:
Zentrale: +49 4307 900 407
Vertrieb: +49 4307 900 402

E-Mail-Adressen:
kontakt@assono.de
bewerbung@assono.de