Heute habe ich auf der SEACON 2012 Flow-Design vorgestellt, ohne es so zu nennen :-) Mein Ansatz war prinzipieller: Für mich ist das, was wofür Flow-Design steht, ein Ergebnis konsequenter Anwendung des Single Responsibility Principle. Flow Design trennt die Verantwortlichkeiten Integration und Operation.
Operation: Hier spielt die Logik-Musik. Hier kommen 3GL-Kontrollstrukturen und Ausdrücke zum Einsatz. Das Ergebnis sind Codeeinheiten, die mit Unit Tests solide abgedeckt sein sollen. Um diese Codeeinheiten überschaubar und leicht testbar zu machen, sind sie unabhängig von einander. Deshalb werden sie über Datenflüsse zu Größerem verbunden.
Integration: Hier werden die Operationen zu Größerem verbunden. Integratoren enthalten keine Kontrollstrukturen oder Ausdrücke. Sie sind frei von solchen Logikkonstrukten. Ihre einzige Aufgabe ist es, Operationen und andere Integratoren zu integrieren. Das geschieht auf beliebig vielen (Abstraktions)Ebenen.
Weil Operationen nicht von einander und am besten auch von keinem gemeinsamen Zustand abhängen sollen, setzen sie auf Datenfluss zur Kommunikation. Weil es um Datenfluss geht, sind Operationen und die daraus entstehenden Integrale eher Aktionen oder Prozess(schritte), denn Akteure. Es geht um Verben statt Substantive. Und weil das so ist, können die entstehenden Hierarchien unmittelbar ausdrücken, wie Code die Funktionalität für Features der Anforderungen herstellt.
Eine Softwarestruktur, die diese Trennung lebt, ist deshalb bestens geeignet, agiles Denken im Code widerzuspiegeln.
Mein Credo:
Process over Data
Wenn wir agil Vorgehen, sollten wir das datenorientierte Denken der bisherigen üblichen Objektorientierung zugunsten eines prozessorientierten Denkens aufgeben. Damit tragen wir auch dem alten Verständnis von Software Rechnung, dass sie als EVA begreift: Eingabe – Verarbeitung – Ausgabe.
Softwarestrukturen für agiles Vorgehen on Prezi
Wer nun mehr über diesen Ansatz erfahren möchte, der kann in den Flow-Design Ressourcen bei den Clean Code Advisors stöbern.
Oder in der dotnetpro meine Artikel verfolgen.
Oder hier meinen Ausflug ins Single Responsibility Principle mitmachen.
Oder nicht nur dieses Blog verfolgen, sondern auch mein englisches Blog lesen. Ich werde mich bemühen, dort mehr zu schreiben, um das Konzept international zur Diskussion zu stellen. Es bewegt sich ja gerade recht viel dabei: Flow-Design wird “entzaubert” durch eine Gründung in fundamentalen Prinzipien. Und Flow-Designs ausführbar zu machen, wird durch die Flow Runtime NPantaRhei noch einfacher.
