API-Patterns: Shared Kernel, Anti-Corruption Layer & Co. – wie bitte?! // deutsch

Summary

In diesem Video werden verschiedene Patterns zur Integration von APIs erläutert, wie das Conformist Pattern, das Anti-Corruption Layer und der Open Host Service. Der Sprecher erklärt, wie diese Konzepte helfen, die Kommunikation zwischen API-Teams und Client-Teams zu standardisieren. Es werden auch weiterführende Ansätze wie das Partnership Pattern, der Shared Kernel und das Separate Ways Pattern vorgestellt, die unterschiedliche Formen der Zusammenarbeit und Isolation zwischen den Teams darstellen. Der Sprecher betont, dass viele dieser Begriffe zwar hilfreich sind, aber nicht unbedingt erforderlich – gesunder Menschenverstand und pragmatische Lösungen können oft genauso effektiv sein.

Takeaways

• 😀 Der Conformist Pattern bedeutet, dass der Client direkt den Vorgaben der API folgt, was in der Regel der einfachste Ansatz für die API-Integration ist.
• 😀 Das Anti-Corruption Layer bietet eine Möglichkeit, einen Adapter zu verwenden, um eine API-Version zu übersetzen, ohne den Client zu verändern.
• 😀 Das Open Host Service Pattern wird verwendet, wenn das API-Team eine flexible Schnittstelle für unterschiedliche Clients zur Verfügung stellt, insbesondere bei einer CQRS-Architektur.
• 😀 Customer-Supplier Patterns beschreiben die hierarchische Beziehung zwischen einem API-Anbieter (Upstream) und einem Client (Downstream), mit unterschiedlichen Ansätzen wie Conformist und Anti-Corruption Layer.
• 😀 Das Partnership Pattern ist eine kooperative Arbeitsweise, bei der API- und Client-Team eng zusammenarbeiten und Änderungen gemeinsam absprechen.
• 😀 Ein Shared Kernel ist eine gemeinsam genutzte Bibliothek von Datentypen oder Validierungslogik, die von mehreren Teams verwendet wird, um die Kommunikation zwischen API und Client zu ermöglichen.
• 😀 Separate Ways bedeutet, dass API- und Client-Teams unabhängig voneinander arbeiten, ohne gemeinsame Absprachen, was oft zu weniger Zusammenarbeit führt.
• 😀 API-Integration muss nicht immer komplex sein; oft genügt es, ein einfaches Verständnis des jeweiligen Patterns zu haben, um eine effiziente Kommunikation zu gewährleisten.
• 😀 Viele der Begriffe und Patterns, die in der API-Entwicklung verwendet werden, sind theoretische Konstrukte, die die Kommunikation vereinfachen, aber nicht unbedingt zwingend erforderlich sind.
• 😀 Das Verständnis von API-Design und den unterschiedlichen Patterns kann dazu beitragen, Missverständnisse in der Zusammenarbeit zwischen verschiedenen Teams zu vermeiden und die Entwicklung zu beschleunigen.

Q & A

Was ist das Conformist Pattern und wie funktioniert es?

Das Conformist Pattern beschreibt eine einfache API-Integration, bei der sich die Clients direkt an die Vorgaben der API-Entwickler halten müssen. Es wird als der Standardansatz bezeichnet, bei dem der Client der API folgt. Der Name kommt daher, dass der Client sich 'konform' zur API verhält.

Was ist ein Anti-Corruption Layer und warum wird er verwendet?

Ein Anti-Corruption Layer ist ein Adapter, der zwischen einem Client und einer API eingesetzt wird, um die Kommunikation zu erleichtern und die Auswirkungen von Änderungen an der API zu minimieren. Der Layer übersetzt die API-Aufrufe, damit der Client nicht direkt auf Änderungen der API reagieren muss.

Was ist der Unterschied zwischen einem Anti-Corruption Layer auf Client- und API-Seite?

Ein Anti-Corruption Layer auf der Client-Seite wird vom Client-Team entwickelt, um den Client von Änderungen der API zu entkoppeln. Auf der API-Seite wird ein Anti-Corruption Layer vom API-Team erstellt, um die API für verschiedene Clients anzupassen und zu erweitern.

Was versteht man unter einem Open Host Service?

Ein Open Host Service bezeichnet eine API, die so gestaltet ist, dass sie vom API-Team für zukünftige Erweiterungen und Anpassungen offen ist. Hierbei handelt es sich um eine dedizierte API, die speziell für bestimmte Kundenanforderungen bereitgestellt wird, um eine flexiblere Integration zu ermöglichen.

Wie unterscheiden sich das Customer-Supplier Pattern und das Partnership Pattern?

Das Customer-Supplier Pattern bezieht sich auf eine Beziehung, bei der das API-Team als 'Supplier' (Anbieter) agiert und das Client-Team als 'Customer' (Kunde). Im Gegensatz dazu ist das Partnership Pattern eine kooperative Zusammenarbeit zwischen API- und Client-Team, bei der beide Parteien gleichberechtigt sind und eng zusammenarbeiten, möglicherweise sogar Code teilen.

Was ist ein Shared Kernel und wie funktioniert es?

Ein Shared Kernel ist eine gemeinsame Bibliothek oder Codebasis, die von mehreren Teams genutzt wird. In einem Partnership Pattern könnten API- und Client-Team einen Shared Kernel verwenden, um bestimmte Datentypen oder Validierungslogiken zu teilen, was die Zusammenarbeit und Kommunikation vereinfacht.

Welche Voraussetzungen müssen erfüllt sein, damit das Partnership Pattern funktioniert?

Für das Partnership Pattern ist es entscheidend, dass es nur wenige Clients gibt, idealerweise nur einen, und dass beide Teams ein starkes gemeinsames Interesse an der Zusammenarbeit haben. Außerdem sollten die Teams auf Augenhöhe arbeiten und eine enge Kommunikation pflegen.

Was passiert, wenn sich API- und Client-Team nicht absprechen wollen?

Wenn API- und Client-Team entscheiden, nicht zusammenzuarbeiten, spricht man vom 'Separate Ways'-Pattern. In diesem Fall arbeiten beide Teams unabhängig voneinander, was zu einer geringen Zusammenarbeit und einer geringeren Flexibilität bei der API-Integration führen kann.

Warum werden diese verschiedenen Integrationsmuster überhaupt benötigt?

Diese Muster helfen dabei, die Kommunikation zwischen API- und Client-Teams zu standardisieren und Probleme wie Versionsänderungen oder Anpassungen der API zu bewältigen. Sie bieten Lösungen für unterschiedliche Anforderungen und ermöglichen eine flexiblere und stabilere API-Integration.

Sind diese Begriffe wie 'Conformist' und 'Anti-Corruption Layer' wirklich notwendig?

Obwohl diese Begriffe manchmal überbewertet erscheinen, bieten sie eine gemeinsame Sprache und einheitliche Verständnisse in der Entwicklergemeinschaft. Sie helfen dabei, komplexe Konzepte in einfache Begriffe zu fassen und die Kommunikation zu vereinfachen.