JAX 08: 5 rules for a better software architecture (Update)

by Thomas Bahn,
assono GmbH, Standort Kiel,


A picture named M2

Alexander von Zitzewitz
5 Regeln für eine bessere Architektur
(5 rules for a better software architecture)

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

Event Technical article JavaScript Java Other

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

Do you want an individual solution? Contact us

More interesting entries

Any questions? Contact us.

If you want to know more about our offers, you can contact us at any time. There are several ways to contact us for a non-binding first consultation.

We don’t sell your data. 100% guaranteed. See: Privacy Policy
assono GmbH

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

Location Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Phone numbers:
Human resources department: +49 4307 900 407
Marketing department: +49 4307 900 402

E-Mail adresses:
contact@assono.de
bewerbung@assono.de