1.
qaware.de
Clean Architecture
Eine praktische Herangehensweise
Dirk Kröhan
dirk.kroehan@qaware.de

2.
QAware | 2
Dirk Kröhan
Software Architect
#qaware #mainz
#cloudnative #spring
#architektur

3.
Motivation

4.
QAware | 4

5.
QAware | 5
Bekannte Probleme & die Suche nach dem heiligen Gral
■ Architekturentscheidungen werden früh getroffen
■ Datenbank steht im Zentrum
■ Fachlichkeit verstreut
■ Dinge zu finden ist schwierig
■ Fehlende Strukturen
■ Transiente Bugs treten öfter auf
■ Aufwand für Änderungen & neue Features steigt
■ Schwergewichtige / langsame Tests

6.
QAware | 6
Siehe auch: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html (August 2012)

7.
Wozu brauchen wir Architektur?

8.
QAware | 8
Architektur
als Publikumsmagnet

9.
QAware | 9
The rules of software architecture...
... are the rules of ordering
and assembling
the building blocks of programs.
- Clean Architecture -

10.
“It works” - Reicht das nicht?
QAware | 10
■ "It works" ist oft schnell zusammengebastelt
■ Ein paar Libraries zusammenstecken -> Fertig
■ Copy&Paste StackOverflow Lösung
■ No-Code- / Low-Code-Editor
■ Compiler braucht keine Architektur

11.
QAware | 11
Das Problem

12.
QAware | 12
Das Problem

13.
Der Mensch als Bottleneck
QAware | 13
■ Software wird von Menschen gebaut
■ Kognitive Fähigkeiten sind limitiert
– Max. Methodenlänge
– Größe einer Klasse
– Komplexität einer Komponente
– Größe eines Systems

14.
QAware | 14
If you think good architecture is
expensive,
try bad architecture.
- Brian Foote and Joseph Yoder -

15.
QAware | 15
Feature
Feature
Release
Feature
Release
Feature
Release
Feature
Release
Release

16.
QAware | 16
The only way to go fast, is to go well.
- Robert C. Martin -

17.
Was ist eine gute Architektur? 🤔

18.
The goal of software architecture is
to minimize the human resources
required to build and maintain the
required system.
- Clean Architecture -
QAware | 18

19.
Messbarkeit von guter Architektur

20.
Messbarkeit von gutem Softwaredesing
QAware | 20
Aufwand um Anforderungen umzusetzen
■ Aufwand gering und bleibt über die Zeit gering → gute Architektur
■ Aufwand steigt mit jedem weiteren Release → schlechte Architektur

21.
Gute Architektur lebt!
QAware | 21
Eine gute Architektur ist mehr als Reise
denn als Ziel zu verstehen, mehr als ein
fortlaufender Prozess denn als ein starres
Artefakt.

22.
Eine gute Architektur soll mir helfen ...
QAware | 22
■ ... ohne viel Aufwand zu verstehen, was ein Service tut.
■ ... neue Anforderung in angemessener Zeit umzusetzen.
■ ... mich auf das Wesentliche zu fokussieren.
■ ... technische Entscheidung nicht voreilig treffen zu müssen.

23.
Clean Architecture

24.
Ziele von Clean Architecture
QAware | 24
■ Unabhängigkeit von Frameworks
■ Unabhängigkeit von User-Interfaces
■ Unabhängigkeit von Datenbanken
■ Unabhängigkeit von anderen externen Schnittstellen / Datenquellen
■ Einfache Testbarkeit der Fachlichkeit

25.
The center of your application is not the
database.
Nor is it one or more of the frameworks
you may be using.
The center of your application are
the use cases of your application.
- Robert C. Martin -
QAware | 25

26.
QAware | 26
Quelle: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

27.
QAware | 27

28.
QAware | 28
Dependency
Inversion
Principle
SOLID Principles

29.
QAware | 29

30.
QAware | 30

31.
QAware | 31

32.
QAware | 32
Quelle: https://github.com/mattia-battiston/clean-architecture-example

33.
Und in der Praxis?

34.
QAware | 34
Spring MVC (@RestController), DTOs / Quartz
Mapping-Code: DTOs ←→ Domain Objects
-------------------------------------------------
Fachlichkeit in @Service Klassen,
Domain Entities,
Data Provider Interfaces
------------------------------------------------
Mapping-Code: Domain Objects ←→ DB Entitäten
JPA/Hibernate, SQL Queries, REST-Templates

35.
QAware | 35

36.
candyshop-cleanarchitecture

37.
Was haben wir heute gelernt?

38.
Zusammenfassung
QAware | 38
■ Fokus auf UseCases und Domain → Screaming Architecture
■ Klare Trennung von Fachlichkeit und technischen Details → Bessere Verständlichkeit
■ Fachlichkeit separiert in UseCases → Single Responsability > Don’t repeat yourself
■ Datenbank und Frameworks bleiben ein Detail → Architekturentscheidungen später treffen
■ Einfache Testbarkeit → Unit-Tests der Fachlichkeit (z.B. mit In-Memory Data Provider)

39.
QAware | 39
Der heilige Gral?

40.
It depends!
QAware | 40
■ Keine One-Fits-All Lösung!
– Für Services mit wenig Fachlichkeit (CRUD Services) eeventuell zu hoher Mapping Aufwand
– Gefühlt viel mehr Code Duplizierung (SRP > DRY)
■ “Build your own naming conventions”
■ Höhere Produktivität!
– Klare Struktur & einfachere Verständlichkeit
– Änderungen einfacher möglich
– Siehe auch “What improves developer productivity at google? code quality” (11/2022)
■ Separation of concern: “The center of your application are the use cases of your application”

41.
Green Software Development Community Meetup
The challenge of putting
software sustainability
research into practice
Sandro Kreten
@ QAware in Munich
Jan 19th, 2023 | 18:30

42.
qaware.de
QAware GmbH Mainz
Rheinstraße 4 C
55116 Mainz
Tel. +49 6131 21569-0
info@qaware.de
twitter.com/qaware
linkedin.com/company/qaware-gmbh
xing.com/companies/qawaregmbh
slideshare.net/qaware
github.com/qaware