This document discusses what makes for a great software architecture and the role of the software architect. It argues that while architecture is important, other factors like automated tests, deployment practices, and understanding customer priorities are also critical for building changeable software. Cyclic dependencies alone do not determine how problematic a codebase is. The software architect's role is to create an architecture that supports business needs while also enabling qualities like changeability, performance and security. There are no universal rules and each project's context is unique.
22. No Automated Tests
> No way to find bugs
> Changes almost impossible
> Legacy code = code without tests
> Michael Feathers
Working Effectively with Legacy Code
24. Automated UI Tests
> Easy to implement
> Exactly what testers do manually
> Easy to understand for customers
> Test business processes
> Safety net
32. Szenario
> Möglicher Ablauf in einer Story
> Standardisierte Bestandteile:
> Gegeben... (Kontext)
> Wenn... (Ereignis)
> Dann... (erwartetes Ergebnis)
33. Szenario: Beispiel
Szenario: Kunde registriert sich erfolgreich
Kontext
Ereignis
Erwartetes
Ergebnis
Erwartetes
Ergebnis
Gegeben ein neuer Kunde mit EMail
eberhard.wolff@gmail.com Vorname Eberhard Name
Wolff
Wenn der Kunde sich registriert
Dann sollte ein Kunde mit der EMail
eberhard.wolff@gmail.com existieren
Und es sollte kein Fehler gemeldet werden
34. RegistrationService registrationService;
// Initialisierung RegistrationService
// ausgelassen
private User kunde;
private boolean fehler = false;
@Given("ein neuer Kunde mit "+
"EMail $email Vorname $vorname"+
" Name $name")
public void gegebenKunde(String email,
String vorname, String name) {
kunde = new User(vorname, name,
email);
}
35. @When("der Kunde sich registriert")
public void registerKunde() {
try {
registrationService.register(kunde);
} catch (IllegalArgumentException ex) {
fehler = true;
}
}
@Then("sollte ein Kunde mit der EMail $email existieren")
public void existiert(String email) {
assertNotNull(registrationService.getByEMail(email));
}
@Then("es sollte kein Fehler gemeldet werden")
public void keinFehler() {
assertFalse(fehler);
} }
37. Tests for Risks
> Algorithm / calculation wrong:
Unit test
> System failures:
Unit tests
> Wiring / collaboration:
Integration tests
> Business process:
Integration test
> UI: UI test
44. Deployment
> Manual deployment is error prone
> Slow deployment
> Lots of code developed but not deployed
> i.e. more lean waste
> Slow feedback
> Slow time to recovery
60. Architecture
> Should support changes
> …with business value
> Needs to model the domain
> Hard to get right
> Architect needs to understand the domain
61. Is a great architecture
free of cyclic
dependencies?