it-swarm.com.de

Saubere Architektur: Abhängigkeitsregel und Bibliotheken / Frameworks

In Clean Architecture von Robert C. Martin zeigt die Abhängigkeitsregel streng von der äußersten Schicht/dem äußersten Ring bis zur innersten.

Als Beispiel sollte ein Dependency Injection Framework auf der äußersten Ebene (Frameworks) liegen, damit es ersetzt werden kann.

Ein DI-Framework, das auf Attributen basiert, würde dies jedoch eindeutig aufheben, da jede Klasse, die diese Attribute benötigt, eine Abhängigkeit vom Framework hätte. Daher konnte eine solche Bibliothek nicht streng nach der Abhängigkeitsregel verwendet werden.

Ich habe das gleiche Problem mit Dienstprogrammbibliotheken, z. eine Mathematikbibliothek oder eine Rx-Bibliothek, die IObservables/Subjects bereitstellt.

Die Mathematikbibliothek könnte von einem Adapter umschlossen werden, um sie austauschbar zu halten - was sinnvoll ist, aber zum Beispiel eine Entität, die das Framework sowohl für Entitäten (innerste Schicht) als auch für Systeme (Geschäftsregeln) und möglicherweise sogar für die Benutzeroberfläche (Präsentatoren) einfach bereitstellt passt nicht gut zu diesem Design.

Selbst für die Mathematikbibliothek klingen die Kosten für das Hinzufügen der Schnittstellen für Dependency Inversion + Adapter ziemlich verrückt.

Vermisse ich etwas oder ist dies mehr oder weniger eine Regel, die häufig beim Versuch, Clean Architecture.

6
Kevin Streicher

Ihre Beobachtung ist richtig. Dies bedeutet jedoch nicht, dass der Ansatz "Saubere Architektur" im Allgemeinen falsch ist.

Eine wichtige Technik zum Entkoppeln von Dingen von "äußeren Ringen" wie der Datenbankschicht oder der Netzwerkschicht von der Geschäftslogik ist die Abhängigkeitsinjektion. Dies kann dazu beitragen, Ihr System von vielen Technologien außer einer zu entkoppeln: dem DI-Framework selbst (falls Sie eine verwenden). Sie können ein System nicht von einem DI-Framework entkoppeln, indem Sie DI anwenden. Wenn Sie eine solche Abhängigkeit vermeiden möchten, besteht die einzige Möglichkeit darin, überhaupt kein DI-Framework zu verwenden und sich an Pure DI zu halten.

Selbst für die Mathematikbibliothek klingen die Kosten für das Hinzufügen der Schnittstellen für Dependency Inversion + Adapter ziemlich verrückt.

Ja, die Vorteile von Abstraktion und Entkopplung sind immer mit Kosten verbunden. Für jede Bibliothek, jedes Tool oder jedes externe System eines Drittanbieters, die Sie verwenden, müssen Sie das Kosten-Nutzen-Verhältnis bewerten, wenn Sie es direkt als "Infrastruktur" Ihres Systems verwenden oder wenn Sie eine Abstraktionsschicht bereitstellen sollten.

Ein guter Lackmustest sind Unit-Tests: Können Sie schnelle und einfache Unit-Tests für Ihre Software ohne zusätzliche Abstraktionsschicht erstellen?

  • für eine Mathe-Bibliothek lautet die Antwort wahrscheinlich "Ja" -> Entkopplung ist den Aufwand möglicherweise nicht wert

  • für eine Datenbankschicht lautet die Antwort oft "Nein" -> eine Entkopplung lohnt sich wahrscheinlich

Dieser Ansatz kann Ihnen bei der Entscheidung helfen, für welche Teile des Systems Sie sich an die "Clean Architecture" halten und für welche Teile Sie diese besser ignorieren.

6
Doc Brown

Der Sinn der sauberen Architektur besteht darin, die Technologie in der Anwendung leicht austauschbar zu machen. Dies geschieht zu Kosten für die Änderung der Änderung der Geschäftslogik .

Wenn Sie also eine Anwendung ausführen, in der eine Änderung der Geschäftslogik (d. H. Die Bereitstellung von Geschäftswert) wahrscheinlicher ist als eine Änderung der Technologien, würde ich vorschlagen, nur die Ideen für eine saubere Architektur vollständig zu ignorieren.

Davon abgesehen bin ich auch kein Fan von Abhängigkeitsinjektions-Frameworks. Normalerweise stört es Ihr Design, daher würde ich es tatsächlich vollständig aus der Anwendung heraushalten.

2