Ich stieß über den Kurs von Matt Rešetár (Reso Coder Labs), welcher die Themen Test Driven Development, Clean Architecture und Flutter behandelt – alles Themen und Inhalte, die ich für wichtig und richtig finde, und für meine IOT Projekte anwende.

Übersicht

Anhand einer Referenzarchitektur nach den Prinzipien von Clean Architecture führt Matt durch eine Serie von Videos und Artikeln durch eine konkrete Implementierung einer Flutter App. Mit dieser App können die Benutzer Informationen zu bestimmten Zahlen von einer REST API im Web einholen und anzeigen lassen. Die App ist nicht mit Features und Besonderheiten überladen, aber komplex genug, um wesentliche Muster für Apps und ihr Zusammenspiel mit verschiedenen Datenquellen zu zeigen.

Architekturebenen

Grob gesagt teilt das Tutorial die Architektur in 3 Ebenen auf:

  • Domäne
  • Daten
  • User Interface

Architecture Overview

Auf dieser Ebene und in jeder Ebene selbst verfolgt Reso einen Middle-Out Ansatz: Ausgehend von der Domäne und ihren Entitäten entwickelt er zunächst in Richtung des Data Layers die Repositories. Dabei enthält die Domäne nur deren Interfaces, während der Data Layer die Implementierungen derselben enthält. Dadurch werden die Repositories mit ihrer Technolgie etc. austauschbar. Mit Hilfe von Mockito kann man die Interfaces relativ leicht mocken und so Ebene für Ebene die zugehörigen Unit Tests schreiben. Im Verlauf des Projekt entsteht so eine Test Suite mit einer guten Abdeckung der Business Logik.

Exception vs. Return Objekte

In der Architektur werden im Data Layer unter Umständen Exceptions geworfen. Diese werden allesamt gefangen und dafür eigene Exceptions geworfen. Auf der Domänen Ebene werden diese Custom Exceptions gefangen und in Return Objekten verpackt. Diese werden dann an das User Interface übergeben und entsprechend visualisiert. Damit ist das Fehlerhandling sehr definiert und artet nicht gleich in Wildwuschs aus.

Für die Rückgabeobjekte werden Futures verwendet, und um die Fehlerobjekte mit einzupacken führt Reso die funktionale Library dartz ein. Mit dem Konstrukt Either kann die App entweder ein Future mit dem Ergebnis zurückliefern oder ein Fehlerobjekt mit weiteren Details zum eigentlichen Fehler. Anfangs war das Handling mit diesem Konstrukt etwas ungewohnt, aber man gewöhnte sich schnell daran, auch weil man viele Unit Tests schrieb und so die API und den Umgang schnell lernte.

Insgesamt kann ich den Kurs nur empfehlen, ich habe sehr viel praktische Erfahrung mit den verschiedenen Prinzipien in kurzer Zeit gesammelt! Und mit einer solchen klaren Architektur weiß ich auch immer genau, wo und wie ich welchen neuen Features oder Erweiterungen einführe und teste.

Referenzen