Lean architecture

Coach für effektive ProduktentwicklungMatthias Bohlen

Lean Architecture

Matthias Bohlen+49 170 772 [email protected]://www.mbohlen.de@mbohlende

Methodless Role

Methodful Role

parameter1

parameter2

Context*1

Domain class

Domain object in role

<<mixin>><<instanceof>>

Donnerstag, 20. September 12

3 Vorträge

2Donnerstag, 20. September 12


Der Spagat

Flexibilität bringt Geschäftje flexibler eine Organisation auf den Markt reagieren kann, desto mehr Geld verdient sie

Flexibilität kostet GeldRefactoring gibt es nicht kostenlosinsbesondere nicht auf Architekturebene

Spagatnur so viel Architektur wie notwendigaber auch so viel wie langfristig hinreichend



Was ist Lean?Denkprinzipien1. Eliminiere Verschwendung2. Verbessere Lernprozesse3. Verzögere Entscheidungen4. Liefere schnell5. Baue Integrität ein6. Ermächtige das Team7. Sieh immer das Ganze!

Nach Mary Poppendieck



Das Ziel von Lean

Wert schaffen ist die Hauptsache

Return on Investment= (Wert - Kosten) / Investition

Wert: raufKosten: runterInvestitionen: klein



Was ist Agilität?

Agilisten schätzen...

6

Individuen und Interaktionen

mehr als Prozesse und Werkzeuge

Funktionierende Software

mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden

mehr als Vertragsverhandlung

Reagieren auf Veränderung

mehr als Befolgen eines Plans


Foto: Casey Hussein Bisson

Wie kann eine Softwarearchitektur

aussehen, die Lean und Agilität

unterstützt?


http://www.flickr.com/photos/maisonbisson/267746261/



Was ist Softwarearchitektur?

8

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



Mentales Modell des Benutzers

Repräsentation im Bewusstsein

★ entscheidende Domänenkonzepte

★ deren Beziehungen untereinander

★ Vorgänge, die auf diesen Domänenkonzepten möglich sind



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!



Tony Hoare, 1980

11

"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."


Form versus Struktur

12

Struktur stützt FormForm ermöglicht Verhalten


Form

"Essenz" der Strukturwahrnehmbar, interessantwertlieferndkonstant

13

Foto: Maik Maid


http://www.flickr.com/photos/frnetz/5175873526/

http://www.flickr.com/photos/frnetz/5175873526/

Struktur

notwendig für die Formwahrnehmbar, doch weniger interessantKosten erzeugendstabil

14

Foto: Ralph Aichinger


http://www.flickr.com/photos/sooperkuh/4568783387/

http://www.flickr.com/photos/sooperkuh/4568783387/

Verhalten

das, was in der Form passieren kanninteressantNutzen stiftendvariabel, flexibel

15Foto: Benjamin Thompson


http://www.flickr.com/photos/beija/4955027468/in/photostream/

http://www.flickr.com/photos/beija/4955027468/in/photostream/

16

Form Struktur Verhalten

Essenz der Struktur

Stütze der Form

was in der Form passiert

wahrnehmbar notwendig interessant

Wertliefernd

Kosten erzeugend

Nutzen stiftend

konstant stabil variabel


16


Essenz der Struktur

Stütze der Form



Wertliefernd

Kosten erzeugend

Nutzen stiftend

konstant stabil variabellean


16


Essenz der Struktur

Stütze der Form



Wertliefernd

Kosten erzeugend

Nutzen stiftend

konstant stabil variabellean agil


Architektur ermittelt zwei Formen

17

Was das System ist

Was das System tut

BenutzertätigkeitenRollen, Aufzeichnungen

EndbenutzerUser Experience Leute

Interface DesignerSich ständig ändernde

Funktionalität

BenutzergedankenKlassen und ObjekteDomänenexpertenArchitektenDatenbankschemataLangzeitstabile Struktur


18

Was das System ist

FormSubsysteme

Interfaces, APIsDomänenobjekte

StrukturModulePaketeKlassen


19

Was das System tut

FormUse CaseKontext

Methodenfreie Rollen

Struktur Methodenreiche RollenAlgorithmen



Mit der Form beginnenFragen Sie die StakeholderAnalysieren Sie die Form des Systems

Partitionierung nach Gemeinsamkeit und Veränderlichkeit

Wählen Sie einen Entwurfsstilmeistens ist das Objektorientierung

Gießen Sie die Form in CodeForm als abstrakte Basisklassen und methodenfreie Rollen

Lassen Sie die Entwicklerteams die Struktur und das Verhalten entwerfen



User Story

Als ein Kontoinhabermöchte ich Geld überweisen

(von meinem Sparkonto auf mein Girokonto)

um etwas anzuschaffen

21

Wer? Akteur = KontoinhaberWas? Tätigkeit = Geld überweisenWarum? Ziel = Anschaffung



Use Case "Geld intern überweisen"

22

Schritt Akteur-Intention Systemverantwortung

1. Kontoinhaber wählt Quellkonto und verlangt Überweisung

Bank zeigt Quellkonto, eine Liste von Zielkonten und ein Feld zur Eingabe des Betrags

2. Kontoinhaber wählt Zielkonto, gibt den Betrag ein und bestätigt

Bank zeigt Überweisungsinformationen (Quellkonto, Zielkonto, Datum, Betrag) und verlangt eine TAN, um die Überweisung zu legitimieren

3. Kontoinhaber gibt TAN ein und bestätigt

Bank bewegt das Geld und führt die Konten.



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.



Vom Was zum Wie

24

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



Vom Was zum Wie

24





Quellkonto



Vom Was zum Wie

24





Quellkonto

Quellkonto und Zielkonto aktualisierenihre Stände.



Vom Was zum Wie

24





Quellkonto

Quellkonto und Zielkonto aktualisierenihre Stände.

Quellkonto


Coach für effektive ProduktentwicklungMatthias BohlenSzenario in Algorithmus umwandeln

25

1.Quellkonto verifiziert, dass genügend Geld da ist

1.Quellkonto verifiziert, dass sein Stand größer ist als der Minimalstand plus Überweisungsbetrag und wirft eine Exception, falls das nicht der Fall ist

2.Quellkonto und Zielkonto aktualisieren ihre Stände

2.Quellkonto reduziert seinen Stand um den Überweisungsbetrag

3.Quellkonto fordert Zielkonto auf, seinen Stand zu erhöhen

3.Quellkonto aktualisiert die Kontoauszüge

4.Quellkonto notiert auf seinem Kontoauszug, dass dies eine Überweisung war

5.Quellkonto fordert Zielkonto auf, auf seinem Kontoauszug eine Überweisung einzutragen.

6.Quellkonto signalisiert Erfolg der Überweisung.



DCI: ein Architektur-Stil

D = DataC = ContextI = InteractionDaten (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!



DCI ist wie eine Theateraufführung

27

Sparkonto Girokonto

Objekt

Kontext: Geld bewegen und Konten führen

Quellkonto Zielkonto

Rolle



DCI Architekturmuster

28

Methodless Role

Methodful Role

parameter1

parameter2

Context*1

Domain class

Domain object in role

<<mixin>><<instanceof>>


Daten

/** * 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

/** * 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" }}


Methodenlose Rollen

/** * 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)}


Methodenreiche Rolle

/** * 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

/** * 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) }}


Kontext

/** * 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) }}


Objekte an Rollen binden (im Kontext)

// this is from class TransferMoneyContext...MoneySource sourceMoneySink 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}


Kleiner Testtreiber für den Use Case

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

def testContext = new TransferMoneyContext()

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

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



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 hineinMischung von Aspekten mit unterschiedlicher Änderungsrate bringt Ärger!

Lösung:Rolle und Objekt auseinanderhalten!



Beispiele für Atomic Events

Ein Buch in einen Einkaufswagen legenEinem 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?



Wie kann man im Team an der Architektur arbeiten?





Agile Architekturrunde:Gemeinsam sind wir Architekten !

40

Benutzer

Entwickler

Business

Domänen-

experte

Architekt

Fachbereich

Analyst

etc.

Designer

Programmierer

Tester

Kunde



Zusammenarbeit

41

Architekturrunde

Saturn-

Team

Neptun-

Team

Architektur

Saturn-BacklogNeptun-Backlog

Saturn Neptun Delegation

Delegation


42

Was das System ist Was das System tut

FormSubsysteme


Use CaseKontext



Methodenreiche Rollen

Algorithmen

Form geht alle an!Form ändert sich seltener als Struktur!


42

Was das System ist Was das System tut

FormSubsysteme


Use CaseKontext



Methodenreiche Rollen

Algorithmen

Form geht alle an!Form ändert sich seltener als Struktur!

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



Schlanke Architektur-Dokumentation





Schlanke Architekturdokumentation

44

Aspekt Bedeutung Medien

Form Subsysteme, APIs, von außen sichtbares Verhalten

Bilder und Vodcasts im Wiki, APIs im Code

Struktur Subsystem-interne Klassen und Schnittstellen

Code

Verhalten wichtige Abläufe im System

Bilder im Wiki, den Rest im Code

Stil Entwurfsprinzipien Wiki



Dokumentation

QuerschnittskonzeptePersistenz, Logging, Transaktionsbehandlung, Authentifizierung, Autorisierung, usw.

Design-EntscheidungenDatum, Ausgangslage, Problemstellung, gewählte/verworfene Optionen, Entscheidungsweg/Begründung, Wiki



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





BDUF und YAGNI, die zwei Extreme

BDUF = Big Design Up Frontheute schon für morgen mitentwerfenkomplett mit allen Detailsdanach alles runtercodierenEntwurf von heute unverändert lassen

YAGNI = You Aren't Gonna Need Itnur das entwerfen und codieren, was heute gebraucht wirdsollte morgen etwas anderes gebraucht werden, den Entwurf von heute ändern



Annahmen hinter BDUF und YAGNI

BDUF:je später wir ändern, desto teurer wird'slanges Nachdenken ist billiger als ändernalso Architektur vor Implementierung

YAGNI:Änderungen sind einfach / kostengünstigÄndern ist billiger als langes Nachdenkenalso Architektur während Implementierung



Mein Vorschlag: DBUF

DBUF = Design the Big things Up FrontEntwirf die "großen Sachen" (Form) vorher,den Rest unterwegs

Was heißt eigentlich "teuer zu ändern"?Form teurer als StrukturStruktur teurer als Verhalten

Struktur basiert auf FormStruktur schaffen ohne Form zu kennen, bedeutet Nacharbeit und Verschwendung



DBUF = Design Big things Up Front

Identifizieren Sie frühzeitigdie komprimierteste Darstellung (Form) von dem, was das System istdie komprimierteste Darstellung (Form) von dem, was das System tut

Dann haben Sie eine gute Grundlage zum Aufbau von StrukturBauen Sie die Struktur erst auf, wenn sie gebraucht wird.



Architektur besteht aus Form, 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

Zusammen-fassung



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



Mehr Info? Hier melden!

Matthias BohlenCoach für effektive Produktentwicklung

Telefon: +49 170 772 8545E-Mail: [email protected]: http://www.mbohlen.de/Twitter: @mbohlende


Nächster Vortrag

54

morgen früh, 09:00 Uhr


Lean architecture

Business

Transcript of Lean architecture