FAQ Category: action domain responder Pattern

Es gibt wenige explizite Erwähnungen von ADR im Embedded-Bereich. Dennoch verwenden viele Systeme ähnliche Strukturen – etwa in der Automobilindustrie, bei IoT-Firmware oder in Echtzeitsystemen. Die Architektur vieler AUTOSAR-Komponenten oder RTOS-basierter Anwendungen folgt einem vergleichbaren Prinzip: Ereignis → Verarbeitung → Ausgabe. ADR lässt sich als methodischer Rahmen dafür nutzen.

Jede Komponente hat eine klar abgegrenzte Aufgabe und kann isoliert getestet werden. Die Domain kann ohne Hardware getestet werden, da sie keine I/O-Funktionalität enthält. Actions können als Reaktion auf simulierte Ereignisse getestet werden. Responder-Tests prüfen nur, ob die richtige Reaktion auf das Domänenergebnis erfolgt. Diese Trennung erleichtert langfristige Wartung erheblich.

Nein, ADR wird derzeit kaum explizit für Embedded C/C++ unterstützt, da es primär aus der Webentwicklung stammt. Die Struktur lässt sich aber leicht manuell nachbilden, insbesondere in C++ mit Klassen oder in C mit Funktionsgruppen und getrennten Modulen. Unit-Test-Frameworks wie GoogleTest, Ceedling oder Catch2 helfen, die einzelnen Komponenten sauber testbar zu halten. Hier ist ein…

Jedes Event (z. B. von einem Interrupt, Timer, Nachricht oder Sensor) wird einer passenden Action zugewiesen. Die Action delegiert an die Domain, die das Event verarbeitet. Danach übergibt die Action das Ergebnis an den Responder, der eine Aktion ausführt oder einen neuen Zustand erzeugt. So lässt sich auch ein nebenläufiges, eventbasiertes System sauber strukturieren.

ADR ist schlanker und direkter. Es reduziert den Abstraktionsaufwand auf drei zentrale Komponenten, während Clean oder Hexagonal Architecture zusätzliche Layer wie Entities, Use Cases oder Interfaces einführen. Für kleine bis mittelgroße Embedded-Systeme bietet ADR einen guten Kompromiss aus Struktur und Einfachheit, ohne die typischen Überladungen komplexer Architekturen.

Der Responder übernimmt die Ausgabe oder Reaktion auf das Ergebnis der Domain. Das kann ein UART- oder CAN-Frame sein, ein GPIO-Pin, ein PWM-Signal oder eine Status-LED. Entscheidend ist, dass der Responder nicht entscheidet, was geschehen soll – sondern nur wie das Ergebnis der Verarbeitung kommuniziert oder umgesetzt wird.

Ja, wenn man es auf abstrakte Rollen überträgt. Statt HTTP-Requests sind es hier z. B. Interrupts, Timer-Events oder Nachrichten. Die Action verarbeitet das Ereignis, die Domain führt die Logik aus, und der Responder erzeugt eine Reaktion (z. B. das Setzen eines Ausgangs oder Senden einer Nachricht). Die Prinzipien bleiben gültig, auch wenn die technische Umgebung ganz anders…

ADR ist eine Weiterentwicklung des MVC-Patterns, speziell für Webanwendungen, aber auch für Systeme mit klar getrennten Verantwortlichkeiten. Im Embedded-Kontext kann ADR eine saubere Trennung von Eingabe-Verarbeitung-Ausgabe bieten, z. B. bei Event-Handling, ohne sich in GUI-spezifische Konzepte zu verlieren.