Auf dieser Website werden Cookies gesetzt, die für den sicheren Betrieb technisch erforderlich sind. Siehe: Datenschutz

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

by Thomas,
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

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


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

Goal 2: Keep complexity under control

Benefits: Dramatic reduction of overall
project cost

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

Subsystems
should have interfaces

Work incrementally

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)

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

You have questions about this article? Contact us: blog@assono.de

Sie wollen eine individuelle Beratung oder einen Workshop? Read more

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.

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