Lean architecture

Matthias Bohlen Coach für effektive Produktentwicklung

Lean Architecture
Context 1 * Methodless Role
parameter1
parameter2

Domain class Methodful Role

<<instanceof>> <<mixin>>

Domain object in role Matthias Bohlen
+49 170 772 8545
mbohlen@mbohlen.de
http://www.mbohlen.de
@mbohlende
Donnerstag, 20. September 12

3 Vorträge

2


Der Spagat
Flexibilität bringt Geschäft
je flexibler eine Organisation auf den Markt
reagieren kann, desto mehr Geld verdient
sie
Flexibilität kostet Geld
Refactoring gibt es nicht kostenlos
insbesondere nicht auf Architekturebene
Spagat
nur so viel Architektur wie notwendig
aber auch so viel wie langfristig hinreichend
3


Was ist Lean?
Denkprinzipien
1. Eliminiere Verschwendung
2. Verbessere Lernprozesse
3. Verzögere Entscheidungen
4. Liefere schnell
5. Baue Integrität ein
6. Ermächtige das Team
7. Sieh immer das Ganze!

Nach Mary Poppendieck



Das Ziel von Lean
Wert schaffen ist die Hauptsache

Return on Investment
= (Wert - Kosten) / Investition

Wert: rauf
Kosten: runter
Investitionen: klein
5


Was ist Agilität?
Agilisten schätzen...
Individuen und mehr als Prozesse und
Interaktionen Werkzeuge
Funktionierende mehr als umfassende
Software Dokumentation
Zusammenarbeit mit dem mehr als
Kunden Vertragsverhandlung
Reagieren auf mehr als Befolgen eines
Veränderung Plans

6

Wie kann eine
Softwarearchitektur
aussehen, die
Lean und Agilität
unterstützt?

Foto: Casey Hussein Bisson 7


Was ist Softwarearchitektur?

Architektur ist die Menge von
Entscheidungen, von denen Sie
wünschten, Sie könnten sie früh im
Projekt richtig treffen (aber bei denen
die Wahrscheinlichkeit, sie richtig zu
treffen, nicht notwendigerweise größer
ist als bei jeder anderen Entscheidung).

Ralph Johnson

8


Mentales Modell des Benutzers

Repräsentation im Bewusstsein

★ entscheidende Domänenkonzepte
★ deren Beziehungen untereinander
★ Vorgänge, die auf diesen
Domänenkonzepten möglich sind

9


Verständliche Architektur
sollte das mentale Modell des Benutzers
wiederspiegeln

Das System sollte sich so verhalten, wie
der Benutzer es erwartet

Die Architektur scheint immer durch, da
kann die Oberfläche so gut sein wie sie
will!
10


Tony Hoare, 1980

"Es gibt zwei Wege, ein Software-
Design zu konstruieren:
• so simpel, dass es offensichtlich
keine Schwächen hat
• so kompliziert, dass es keine
offensichtlichen Schwächen hat.
Die erste Methode ist weitaus
schwieriger."

11

Struktur stützt Form
Form versus Struktur Form ermöglicht Verhalten

12

Form
"Essenz" der Struktur
wahrnehmbar, interessant
wertliefernd
konstant

Foto: Maik Maid

13

Struktur
notwendig für die Form
wahrnehmbar, doch weniger interessant
Kosten erzeugend
stabil

Foto: Ralph Aichinger

14

Verhalten
das, was in der Form passieren kann
interessant
Nutzen stiftend
variabel, flexibel

Foto: Benjamin Thompson
15

Form Struktur Verhalten

Essenz der Stütze der was in der
Struktur Form Form passiert

wahrnehmbar notwendig interessant

Wert Kosten Nutzen
liefernd erzeugend stiftend

konstant stabil variabel

16



n

lea
Wert Kosten Nutzen


16



n

il
lea
ag
Wert Kosten Nutzen


16

Architektur ermittelt Benutzertätigkeiten
Rollen, Aufzeichnungen
zwei Formen Endbenutzer
User Experience Leute
Interface Designer
Wa Sich ständig ändernde
sd Funktionalität
Wa as
sd Sy
as ste
Sy m
Benutzergedanken ste tu
m t
Klassen und Objekte ist
Domänenexperten
Architekten
Datenbankschemata
Langzeitstabile Struktur

17

Was das System ist

Subsysteme
Form Interfaces, APIs
Domänenobjekte

Module
Struktur Pakete
Klassen
18

Was das System tut

Use Case
Form Kontext
Methodenfreie Rollen

Methodenreiche Rollen
Struktur
Algorithmen

19


Mit der Form beginnen
Fragen Sie die Stakeholder
Analysieren Sie die Form des Systems
Partitionierung nach Gemeinsamkeit und Veränderlichkeit
Wählen Sie einen Entwurfsstil
meistens ist das Objektorientierung
Gießen Sie die Form in Code
Form als abstrakte Basisklassen und methodenfreie Rollen
Lassen Sie die Entwicklerteams die Struktur und das
Verhalten entwerfen

20


User Story

Als ein Kontoinhaber
möchte ich Geld überweisen
(von meinem Sparkonto auf mein Girokonto)
um etwas anzuschaffen

Wer? Akteur = Kontoinhaber
Was? Tätigkeit = Geld überweisen
Warum? Ziel = Anschaffung
21


Use Case "Geld intern überweisen"
Schritt Akteur-Intention Systemverantwortung

1. Kontoinhaber wählt Bank zeigt Quellkonto, eine
Quellkonto und Liste von Zielkonten und ein
verlangt Überweisung Feld zur Eingabe des Betrags

2. Kontoinhaber wählt Bank zeigt
Zielkonto, gibt den Überweisungsinformationen
Betrag ein und (Quellkonto, Zielkonto,
bestätigt Datum, Betrag) und verlangt
eine TAN, um die
Überweisung zu legitimieren

3. Kontoinhaber gibt TAN Bank bewegt das Geld und
ein und bestätigt führt die Konten.

22


Vom Use Case zur Technik
"Geld überweisen" ist etwas Fachliches
"Geld bewegen und Konten führen" ist
etwas eher Mechanisches

Letzteres nennen wir eine Gewohnheit.
Im Architekturteam finden wir eine Form
für diese Gewohnheit und überlassen es
dem Entwicklungsteam, die Struktur
dafür aufzubauen.
23


Vom Was zum Wie
Schritt Geld bewegen und Konten führen
1. Bank verifiziert, dass genügend Geld da ist

2. Bank aktualisiert die Konten

3. Bank aktualisiert die Kontoauszüge

24


Vom Was zum Wie
Quellkonto



24


Vom Was zum Wie
Quellkonto

Quellkonto und Zielkonto aktualisieren
ihre Stände.


24


Vom Was zum Wie
Quellkonto

Quellkonto und Zielkonto aktualisieren
ihre Stände.

Quellkonto

24


Szenario in Algorithmus umwandeln
1.Quellkonto 1.Quellkonto verifiziert, dass sein Stand
verifiziert, größer ist als der Minimalstand plus
dass genügend Überweisungsbetrag und wirft eine
Geld da ist Exception, falls das nicht der Fall ist
2.Quellkonto 2.Quellkonto reduziert seinen Stand um den
und Zielkonto Überweisungsbetrag
aktualisieren 3.Quellkonto fordert Zielkonto auf, seinen
ihre Stände Stand zu erhöhen
3.Quellkonto 4.Quellkonto notiert auf seinem Kontoauszug,
aktualisiert dass dies eine Überweisung war
die 5.Quellkonto fordert Zielkonto auf, auf
Kontoauszüge seinem Kontoauszug eine Überweisung
einzutragen.
6.Quellkonto signalisiert Erfolg der
Überweisung.
25


DCI: ein Architektur-Stil
D = Data
C = Context
I = Interaction
Daten (repräsentiert durch
Domänenobjekte) spielen interagierende
Rollen innerhalb eines Kontextes, der
dem Use Case entspricht.
Das soll man im Code auch so sehen
können!
26


DCI ist wie eine Theateraufführung
Kontext: Geld bewegen und Konten führen

Quellkonto Zielkonto
Rolle

Objekt
Sparkonto Girokonto

27


DCI Architekturmuster
Context 1 * Methodless Role
parameter1
parameter2

Domain class Methodful Role

<<instanceof>> <<mixin>>

Domain object in role

28

/**
* Domain class that captures the concept of a
* bank-internal account in general.
*/
class Account {
private Long balance = 0L

Long availableBalance() { balance }

def increaseBalance(amount) {
balance += amount
}

def decreaseBalance(amount) {
balance -= amount
}

def updateLog (msg, date, amount) {
println toString() + " Account: $msg, $date, $amount"
}
}

Daten
29

/**
* Domain class that captures the concept of a savings
* account.
*/
class SavingsAccount extends Account {
String toString() { "Savings" }
}

/**
* Domain class that captures the concept of a checking
* account.
*/
class CheckingAccount extends Account {
String toString() { "Checking" }
}

Daten
30

/**
* Methodless role that captures the form (interface)
* of one part of the Transfer behavior
*/
interface MoneySource {
def transferTo (Long amount, MoneySink recipient)
}

/**
* Methodless role that captures the form (interface)
* of the other part of the Transfer behavior
*/
interface MoneySink {
def transferFrom (Long amount, MoneySource source)
}

Methodenlose Rollen
31

/**
* Methodful role for the source account
* for the money transfer.
*/
class TransferMoneySource implements MoneySource {

def transferTo (Long amount, MoneySink recipient) {
// This code is reviewable and
// meaningfully testable with stubs!
if (availableBalance() < amount) {
throw new InsufficientFundsException()
}
else {
decreaseBalance (amount)
recipient.transferFrom (amount, this)
updateLog ("Transfer Out", new Date(), amount)
}
}

}

Methodenreiche Rolle
32

/**
* Methodful role for the recipient account
* for the money transfer.
*/
class TransferMoneySink implements MoneySink {

def transferFrom (Long amount, MoneySource source) {
increaseBalance (amount)
updateLog ("Transfer In", new Date(), amount)
}
}

Methodenreiche Rolle
33

/**
* Context of the "Transfer Money" use case.
*/
class TransferMoneyContext {
MoneySource source
MoneySink recipient
Long amount

def bindObjects() {
// find objects and assign to source & recipient.
// this would normally be a database lookup!
}

def doIt() {
source.transferTo (amount, recipient)
}
}

Kontext
34

// this is from class TransferMoneyContext...
MoneySource source
MoneySink recipient

def bindObjects() {
// this would normally be a database lookup!
def savings = new SavingsAccount()
savings.increaseBalance (1000L)
def checking = new CheckingAccount()

// now mix-in the roles of these objects
// so that each object gets the methods needed by
// the use case and by the other roles.

savings.metaClass.mixin TransferMoneySource
checking.metaClass.mixin TransferMoneySink

this.source = savings as MoneySource
this.recipient = checking as MoneySink
}

Objekte an Rollen binden (im Kontext)
35

// -------------------------------------------------------
// -- Test driver --
// -------------------------------------------------------

def testContext = new TransferMoneyContext()

testContext.amount = 200
testContext.bindObjects()
testContext.doIt()

assert 800 == testContext.source.availableBalance()
assert 200 == testContext.recipient.availableBalance()

Kleiner Testtreiber für den Use Case
36


Anderer Stil: Atomic Events Architecture
In vielen Anwendungen sind Use Cases
tatsächlich Overkill
es geht um Events, die auf Objekte wirken
Problem:
Wenn man nicht aufpasst, designt man
Rollenmethoden ins Domänenobjekt hinein
Mischung von Aspekten mit unterschiedlicher
Änderungsrate bringt Ärger!
Lösung:
Rolle und Objekt auseinanderhalten!
37


Beispiele für Atomic Events
Ein Buch in einen Einkaufswagen legen
Einem Rechteck eine neue Farbe geben

Doch Vorsicht:
Was ist mit Undo auf die Farbe des
Rechtecks?
Was ist, wenn mehrere Rechtecke
gleichzeitig eingefärbt werden sollen?

38

Wie kann man im Team an
der Architektur arbeiten?



Agile Architekturrunde:
Gemeinsam sind wir Architekten !

Benutzer

Business Kunde

Architekt Designer
Fachbereich Domänen- Entwickler Programmierer
Analyst experte Tester
etc.

40


Zusammenarbeit Architekturrunde
Delegation

Delegation
Saturn Architektur Neptun
Saturn-Backlog Neptun-Backlog

Saturn- Neptun-
Team Team
41

Form geht alle an!
Form ändert sich seltener als Struktur!
Was das System ist Was das System tut
Use Case
Subsysteme
Kontext
Methodenfreie
Domänenobjekte
Rollen
Module Methodenreiche
Struktur Pakete Rollen
Klassen Algorithmen

42

Form geht alle an!
Form ändert sich seltener als Struktur!
Was das System ist Was das System tut
Use Case
Subsysteme
Kontext
Methodenfreie
Domänenobjekte
Rollen
Module Methodenreiche
Struktur Pakete Rollen
Klassen Algorithmen

Daher: Im Architekturteam die Form aufbauen,
in den anderen Teams die Strukturen schaffen!
42

Schlanke Architektur-
Dokumentation



Schlanke Architekturdokumentation
Aspekt Bedeutung Medien

Form Subsysteme, APIs, von Bilder und
außen sichtbares Vodcasts im Wiki,
Verhalten APIs im Code
Struktur Subsystem-interne Code
Klassen und
Schnittstellen
Verhalten wichtige Abläufe im Bilder im Wiki,
System den Rest im Code
Stil Entwurfsprinzipien Wiki

44


Dokumentation
Querschnittskonzepte
Persistenz, Logging,
Transaktionsbehandlung, Authentifizierung,
Autorisierung, usw.
Design-Entscheidungen
Datum, Ausgangslage, Problemstellung,
gewählte/verworfene Optionen,
Entscheidungsweg/Begründung, Wiki

45

Plädiert der Bohlen jetzt
etwa für den Wasserfall?



BDUF und YAGNI, die zwei Extreme
BDUF = Big Design Up Front
heute schon für morgen mitentwerfen
komplett mit allen Details
danach alles runtercodieren
Entwurf von heute unverändert lassen
YAGNI = You Aren't Gonna Need It
nur das entwerfen und codieren, was heute
gebraucht wird
sollte morgen etwas anderes gebraucht
werden, den Entwurf von heute ändern
47


Annahmen hinter BDUF und YAGNI
BDUF:
je später wir ändern, desto teurer wird's
langes Nachdenken ist billiger als ändern
also Architektur vor Implementierung
YAGNI:
Änderungen sind einfach / kostengünstig
Ändern ist billiger als langes Nachdenken
also Architektur während Implementierung

48


Mein Vorschlag: DBUF
DBUF = Design the Big things Up Front
Entwirf die "großen Sachen" (Form) vorher,
den Rest unterwegs
Was heißt eigentlich "teuer zu ändern"?
Form teurer als Struktur
Struktur teurer als Verhalten
Struktur basiert auf Form
Struktur schaffen ohne Form zu kennen,
bedeutet Nacharbeit und Verschwendung

49


DBUF = Design Big things Up Front
Identifizieren Sie frühzeitig
die komprimierteste Darstellung (Form) von
dem, was das System ist
die komprimierteste Darstellung (Form) von
dem, was das System tut
Dann haben Sie eine gute Grundlage zum
Aufbau von Struktur
Bauen Sie die Struktur erst auf, wenn sie
gebraucht wird.

50


Zusammen- Architektur besteht aus Form,
fassung Struktur und Stil
Sie sollte das mentale Modell des
Users widerspiegeln (Konzepte
und deren Verhalten)
Lean sind wir, indem wir die
Form "früh" richtig hinbekommen
Agil sind wir, indem wir innerhalb
dieser Form "spät" und "schnell"
Strukturen ändern und Verhalten
schaffen
51


Literatur
James Coplien, Gertrud Bjornvig:
"Lean Architecture", Wiley & Sons 2010

Trygve Reenskaug:
http://folk.uio.no/trygver
"The Common Sense of Object Orientated
Programming"
http://folk.uio.no/trygver/2008/
commonsense.pdf

52


Mehr Info? Hier melden!

Matthias Bohlen
Coach für effektive Produktentwicklung

Telefon: +49 170 772 8545
E-Mail: mbohlen@mbohlen.de
Web: http://www.mbohlen.de/
Twitter: @mbohlende

Nächster Vortrag

morgen früh, 09:00 Uhr

54

Lean architecture

Weitere ähnliche Inhalte

Andere mochten auch

Mehr von Matthias Bohlen

Lean architecture