Bild aus dem tomaszjaniak Blog
Zeigen Sie uns Ihre Architektur
Es kommt also vor, dass Sie seit ein paar Jahren an einem Projekt arbeiten und jetzt im Code bis an die Ellbogen sitzen, die Tests brennen, der Laptop-Kühler Geräusche macht und versucht, die vom Compiler überhitzte Prozessorwärme zu kühlen, nur noch ein paar Stunden - und das Refactoring ist abgeschlossen. Und dann müssen wir dringend alles fallen lassen und die Architektur des Projekts zeichnen. Ein großer Kunde ist geplant, und um den Deal abzuschließen, muss ein Audit durchgeführt werden. Und in diesem Fall gibt es keinen Ort ohne Architekturdiagramme. Was ist, wenn das Projekt noch klein ist und ein Dutzend seiner Entwickler in der realen Arbeit dort keine Architektur benötigt? Hier ist der Code - alles ist klar. Aber es gibt keinen Ausweg. Es ist notwendig - dann ist es notwendig.
Wenn Sie wissen, wie alles funktioniert, kann die Architektur eines Produkts in einer Stunde gezeichnet werden. Und das reicht normalerweise für ein Audit. Schließlich geht es bei der Prüfung nicht darum, dass Außenstehende Ihre Produktarchitektur wirklich verstehen. Der springende Punkt der Frage ist, festzustellen, ob die Produktentwickler selbst verstehen, was sie tun. Und wenn Sie sicher genug sprechen und Fragen ohne zu zögern beantworten, läuft alles reibungslos. Aber dennoch, wenn diese Geschichte endet, wird sich irgendwo in der Tiefe ein Wurm niederlassen, was die Frage schärfen wird: Aber welche Art von Architektur hat das Produkt tatsächlich? Wenn sie fragen, haben wahrscheinlich andere Architektur. Und wenn wir es nicht haben, ist dies eindeutig ein Chaos. Es besteht ein großer Wunsch, alles gut zu machen, um beim nächsten Mal so für die Architektur verantwortlich zu sein, wie es sein sollte.
Wie machst du es richtig? Sie müssen Diagramme zeichnen, Funktionen in Dokumenten beschreiben und dies alles auf dem neuesten Stand halten. Dann wird es Architektur sein. Nach der Darstellung des Arbeitsumfangs wird jedoch schnell klar, dass all dies die aufgewendete Zeit nicht wert ist. Hier ist der Code - alles ist klar. Und wenn ein anderer Kunde kommt, ist es in einer weiteren Stunde möglich, ein neues Diagramm zu zeichnen.
Und nach einigen Jahren befinden Sie sich möglicherweise in der entgegengesetzten Situation, und die Dokumente, die die Architektur eines anderen Produkts beschreiben, werden nicht besser sein. Natürlich ist es nützlich zu wissen, dass andere auch eine sehr schlechte Architektur haben. Wenn jedoch die Größe des Projekts in Millionen von Codezeilen und die Anzahl der Entwickler in Hunderten gemessen wird, wird die Frage nach der Notwendigkeit einer Architektur immer noch von Bedeutung.
Hier werden im Rahmen des Workflows verschiedene Architekturdiagramme angezeigt, Architekturvorschläge beginnen, auf Features zu schreiben, all dies wird diskutiert, überprüft, validiert, genehmigt und ist natürlich veraltet, noch bevor diese Prozesse abgeschlossen sind. Es muss nicht gesagt werden, dass solche Dokumente die tatsächliche Struktur des Anwendungscodes widerspiegeln. Und wenn es um die Implementierung geht, lesen die Entwickler diese Dokumente überhaupt nicht. Oder es wird etwas völlig anderes implementiert als das, was geschrieben wurde. Jemand hat jemanden missverstanden, oder es war dringend nötig, und es gab keine Zeit zu diskutieren.
Vielleicht ist alles so, wie es sein sollte. Vielleicht ist Architektur die Bürokratie um spekulative Dokumente, die von der Realität getrennt sind? Aber die Intuition sagt uns, dass nein. Was ist dann "Architektur"?
Architektur ist ...
Was passiert, wenn Sie die Frage "Was ist Architektur?" Stellen. zehn professionelle Entwickler? Wenn Sie nicht in Wikipedia stöbern, geben sie dann die gleiche Antwort?
Architektur besteht sowohl aus einer Reihe wichtiger Entscheidungen und der Struktur von Elementen und ihren Schnittstellen als auch aus einem System von Bestimmungen, Regeln und Vereinbarungen sowie gebildeten Ansätzen, die Ordnung und Lösungen für globale Probleme und die Zerlegung durch Interaktion aufrechterhalten, sowie aus einer allgemeinen Beschreibung des Systems und seines Lebenszyklus. Teile und Muster von Struktur und Verhalten und was schwierig oder teuer zu ändern oder zu entfernen ist, und grundlegende Entscheidungen und Kompromisse und vieles mehr.
Architektur ist auch, wie eine Anwendung ihren beabsichtigten Zweck erfüllt.
API ist eine Architektur, ein Datenschema ist auch eine Architektur und eine Struktur von Modulen und Diensten. Es gibt eine Anwendungsskalierungsarchitektur, eine Anwendungszuverlässigkeitsarchitektur, eine Komponenteninteraktionsarchitektur und eine Sicherheitsarchitektur. Und natürlich hat jedes Feature seine eigene Architektur. Und das alles zusammen ist auch Architektur.
Kann all dies als Antwort auf die Frage "Was ist Architektur?" - vielleicht ja. Alles scheint richtig zu sein, alles scheint klar zu sein. Aber ist diese Antwort praktisch nützlich und kann in einem echten Workflow verwendet werden? Nicht wirklich.
Woher wissen Sie, ob eine Entscheidung wichtig oder grundlegend ist? Was sind globale Herausforderungen? Was bedeutet es teuer oder billig? Wie schätzen Sie die Komplexität ein? Wo liegt die Grenze zwischen High-Level und Low-Level? Was ist Ordnung? Was ist der Zweck des Systems?
Dies sind alles Fragen, die Sie auch beantworten können. Formulieren Sie Definitionen, erklären Sie mit Beispielen, organisieren Sie im schlimmsten Fall den Entscheidungsprozess. Aber es wird immer noch etwas Kontroverses, etwas Intuitives bleiben, abhängig von der persönlichen Wahrnehmung und von jedem ein wenig auf seine Weise verstanden. Dies bedeutet, dass es immer Konflikte geben wird, die darauf beruhen, dass unterschiedliche Menschen dieselbe Situation auf radikal unterschiedliche Weise interpretieren. Entwickler werden sich beschweren, dass Architekten Implementierungsdetails manipulieren, Architekten, dass Entwickler die Architektur brechen. Wenn es keine klare Grenze gibt, sind Konflikte unvermeidlich.
Jeder hat wahrscheinlich ein allgemeines Verständnis dafür, was Architektur ist. Es ist jedoch schwierig, eine einzige, formal verifizierte und mathematisch genaue Definition zu nennen.
Auf der anderen Seite, wenn Sie fragen "Was ist Realisierung?" - Die Antwort ist wahrscheinlich eindeutig: "Hier ist ein Link zum Code-Repository!" Und damit kann man nicht streiten. Und es gibt keine Zweifel oder Unklarheiten bei der Interpretation dieser Antwort. 1 + 1 = 2, Implementierung ist Code.
Und der Code ist sehr einfach zu bearbeiten. Wenn Sie die Implementierung verstehen möchten, können Sie das Projekt in der Entwicklungsumgebung öffnen. Wenn Änderungen im Code überprüft werden müssen, gibt es Zweige im Repository. Wenn es Zeit ist, eine neue Version der Anwendung zu veröffentlichen, werden Tests gestartet.
Natürlich kann die Struktur des Projekts verwirrend sein, die Überprüfungen sind von schlechter Qualität und die Testabdeckung ist unvollständig. Aber zumindest bei der Arbeit mit Code ist immer klar, was und wann zu tun ist.
Aber was wäre, wenn die Architektur genau wie die Implementierung in Code ausgedrückt würde?
Viele gängige Programmiersprachen werden in der modernen Entwicklung verwendet. Die meisten von ihnen sind vor langer oder sehr langer Zeit erschienen. Und während sie noch gut sind, sind sie immer noch veraltet. Dies sind schwach typisierte Sprachen: JavaScript, Python, PHP, Ruby und stark typisierte Sprachen: Java, C / Objective-C / C ++, C #. Sie werden durch neue Sprachen ersetzt, die im Rahmen derselben Plattform versuchen, alte Probleme zu lösen, indem sie mit syntaktischem Zucker bestreut werden, ohne jedoch grundlegend neue Konzepte einzuführen, wenn Sie global schauen: Swift, Kotlin, TypeScript, Go. Dies sind alles Sprachen, die auf dem objektorientierten Paradigma basieren. Auch der funktionale Programmieransatz hat an Popularität gewonnen, der sowohl in den aufgelisteten Sprachen implementiert als auch in Fachsprachen präsentiert wird, aber weniger beliebt ist: Erlang, F #.Sprachen, die wesentlich neue Konzepte implementieren, werden ebenfalls immer beliebter: Rust, Haskell.
All diese Vielfalt hat eines gemeinsam: Sie sind alle Implementierungssprachen. Keine dieser Programmiersprachen ist Ausdruck der Architektur. Es gibt jedoch eine Ausnahme - SQL.
SQL ist die einzige gängige Programmiersprache, die deklarativ ist. Es basiert auf einem relationalen Algebra-Modell und ist eng spezialisiert - es arbeitet mit gespeicherten Daten. Aber warum kann SQL dennoch als die Sprache der Architektur angesehen werden?
Zunächst bietet SQL Zugriff auf Metainformationen zum Datenschema. Sie können problemlos eine Liste mit Tabellen, Spalten, Beziehungen, Indizes, Ansichten, Rollen und mehr aus der Datenbank abrufen. Die Dokumentation des Speicherschemas und die Möglichkeit, es zu visualisieren, sind eine große Hilfe beim Verständnis der Struktur einer Anwendung. Eine Datenschemabeschreibung ist eine Art Architekturbeschreibung auf hoher Ebene.
Zweitens bietet SQL eine Datenabfragesprache, mit der der Client eine beliebige im Schema beschriebene Datenkombination abfragen kann. Wenn es keine Abfragesprache gäbe, müsste für jedes vom Client benötigte Datenmodell entweder eine separate API-Methode implementiert werden, oder der Client müsste mehrere API-Aufrufe an verschiedene Teile des Datenschemas senden und das erforderliche Modell auf seiner Seite kombinieren. Das Vorhandensein der Abfragesprache ermöglicht es, die Implementierungsdetails, die mit der Aufzählung von API-Methoden zum Abrufen bestimmter Datenmodelle gemäß dem allgemeinen Schema verbunden sind, aus der Beschreibung der Architektur auszuschließen. Die Abfragesprache schließt Implementierungsdetails aus der Beschreibung der Architektur aus.
SQL bietet drei Schlüsseleigenschaften, die für die Beschreibung der Architektur wichtig sind:
- Deklarativität - Mit SQL können Sie die Beschreibung der Architektur von ihrer Implementierung trennen.
- Analysierbarkeit - SQL bietet Zugriff auf Metainformationen eines Datenschemas, mit denen Sie dessen Darstellungen visualisieren, dokumentieren und analysieren können.
- Korrektheit - Mit SQL können Sie die Einschränkungen des Datenmodells definieren, wodurch eine Vielzahl von Verstößen gegen die Datenintegrität durch die Implementierung verhindert werden kann.
Möglicherweise kann SQL als Tool zur Beschreibung der Architektur im Hinblick auf die Datenspeicherung bezeichnet werden, aber es reicht eindeutig nicht aus, die vollständige Architektur eines Produkts zu beschreiben.
Andere Mittel zur Beschreibung der Architektur
Das direkte Analogon von SQL ist GraphQL, mit dem Sie auch das Datenschema definieren und über die Abfragesprache darauf zugreifen können. Gleichzeitig basiert GraphQL auf der Graphentheorie und nicht auf einem relationalen Algebra-Modell. Dies ermöglicht eine natürlichere Arbeit mit hierarchischen Datenmodellen im Gegensatz zu SQL, wo die Arbeit mit Hierarchien schwierig sein kann.
GraphQL wird häufig als Client-Server-Kommunikationslösung beworben, dies ist jedoch nicht der einzige Anwendungsbereich. In ähnlicher Weise können Sie über GraphQL eine Server-zu-Server-Kommunikation und sogar eine Server-zu-Basis-Kommunikation bereitstellen. Die Tatsache, dass moderne Datenbanken nur eine SQL-Schnittstelle bieten, aber keine bequeme API für die Arbeit mit hierarchischen Abfragen bieten, ist eine beleidigende Auslassung.
Wenn SQL ein Mittel zur Beschreibung der Architektur des Datenspeicherschemas ist, können Sie mit GraphQL die Architektur des Datensschemas bereits auf Unternehmensebene anhand eines bestimmten Anwendungsbereichs beschreiben. In diesem Sinne können Sie mit GraphQL die Architektur auf einer höheren Ebene definieren, die näher am tatsächlichen Anwendungsbereich des Produkts liegt.
Codemodule und Microservices sind zusammen mit ihren APIs und Abhängigkeiten auch Mittel, um Architektur in Bezug auf Struktur und Beziehungen auszudrücken.
Architektur und Implementierung
Für ein kleines Projekt, an dem ein Dutzend Entwickler arbeiten, ist häufig keine separate Beschreibung der Architektur erforderlich. Wenn der Projektcode ordentlich und gut strukturiert geschrieben ist, kann dies ausreichen, um das Gesamtbild und die Entwicklungsrichtungen zu verstehen.
Während das Projekt wächst, werden verschiedene Dokumente angezeigt, die sowohl die allgemeine Architektur als auch Details zu neuen Teilen und wichtige Verbesserungen beschreiben. Dies ist ein ziemlich funktionierender Ansatz, wenn mehrere Dutzend Menschen an einem Projekt arbeiten.
Bei einem ziemlich großen Projekt mit Hunderten von Entwicklern schlägt dieser Ansatz jedoch fehl. Es gibt zu viele Dokumente, und ihr Inhalt weicht immer mehr von der Implementierung ab. Es wird immer schwieriger, Gedanken für alle gleich auszudrücken. Rallyes für Dutzende von Menschen werden organisiert, um viele private Themen zu diskutieren, während wirklich wichtige Änderungen ohne Diskussion durchgeführt werden können. All dies führt dazu, dass immer mehr Prozesse organisiert werden müssen, wenn einige etwas anbieten müssen, andere folgen, andere überprüfen und wieder andere dies tun. Bürokratie. Infolgedessen beginnen Entwickler, mehr Dokumente und weniger Code zu schreiben, und dies ist nicht das größte Problem.
Natürlich ist an der Bürokratie als solcher nichts auszusetzen. Bei jeder Arbeit ist die Organisation wichtig. Das Problem ist die Bürokratie pro Einheit nützlicher Arbeit. Wenn Sie, um Eins zu machen, zwei weitere, drei, vier, fünf Besprechungen abhalten müssen, ist dies nirgendwo mehr gut.
Selbst eine einfache Frage, welche Änderung der Entwickler selbst vornehmen kann, weil es sich um eine Implementierung handelt und wofür eine Anforderung für eine Überprüfung erforderlich ist, da es sich um eine Architektur handelt, führt zu Schwierigkeiten. Sie müssen sich eine Vielzahl von Architekturauslösern einfallen lassen. Wenn Sie das Datenschema ändern oder Kryptografie- und Sicherheitsprobleme ansprechen, muss dies architektonisch überprüft werden, und andere Themen scheinen dies nicht zu sein, aber dies ist nicht sicher. All dies muss nicht nur Hunderten von Entwicklern formuliert und erklärt werden, sondern auch sicherstellen, dass die beschriebenen Regeln eingehalten werden. Ein solcher Prozess wird ständig scheitern.
All diese Probleme hängen mit dem Fehlen einer klaren Definition der Architektur zusammen.
So wie das Ändern einer ".java" -Datei in einem Repository eindeutig eine Änderung der Implementierung anzeigt, kann das Ändern einer ".architecture" -Datei eine Änderung der Architektur anzeigen. Natürlich existieren ".architecture" -Dateien in der Natur nicht. Für jedes Projekt können Sie jedoch definieren, welche Aspekte sich speziell auf seine Architektur beziehen, und es explizit machen.
Wenn eine Änderung des Datenschemas als Änderung der Architektur betrachtet wird, müssen sich die Dateien, die die SQL-Migrationen enthalten, auf die Architektur beziehen. Wenn die API auch Teil der Architektur ist, können Sie die API in Form derselben Swagger-Dateien definieren und sich auf diese verlassen. Wenn die Struktur der Module Architektur ist, ist die Änderung in der Beschreibung der Module eine Architekturänderung. Usw.
Nicht alle Aspekte der Architektur können mit Standardmitteln ausgedrückt werden. Jedes Projekt hat seine eigenen Besonderheiten. Wenn das Produkt beispielsweise ein bestimmtes Modell von Rechten, Rollen, Abonnementtypen, Add-Ons usw. verwendet, sollten Sie darüber nachdenken, die Architektur dieses Aspekts des Produkts in einer geeigneten deklarativen Form zu definieren und dabei das Wesentliche der Architektur anhand der Implementierungsdetails hervorzuheben. Natürlich können solche Änderungen erhebliche Code-Nacharbeiten erfordern. Dies ist jedoch eine wesentlich bessere Investition in die Definition einer Produktarchitektur als der Versuch, ihr Rechte-Modell in einem Dokument zu beschreiben.
Eine formale Darstellung der Architektur im Code ist möglich, und nur dies gibt eine klare Definition dessen, was eine Architektur ist. Diese Ansicht ermöglicht es, die Architektur zu analysieren und automatisch eine Dokumentation zu generieren, die immer auf dem neuesten Stand ist. Alles andere: Dokumente, Diagramme und Diagramme von Hand - Bürokratie.
Eine Architektur kann einen formalen Ausdruck im Code haben, und nur dies definiert eine klare Grenze zwischen Architektur und Implementierung. Und eine solche Grenze wird benötigt.
Ingenieurwesen und evolutionäre Ansätze in der Architektur
Während des letzten halben Jahrhunderts hat die Entwicklungsindustrie einen langen Weg von Wasserfallmodellen zur iterativen Entwicklung zurückgelegt. Und jetzt scheint die Branche in dieser Angelegenheit zu weit gegangen zu sein. An einigen Stellen ähnelt die Arbeit eines Architekten nicht mehr der eines Ingenieurs oder sogar eines Gärtners, und sie ähnelt immer mehr der Arbeit eines Saisonarbeiters, der ausschließlich zum Jäten von Betten eingestellt wurde.
Was Technik von Handwerk unterscheidet, ist das Verständnis der Naturgesetze, auf deren Grundlage man Berechnungen und Schlussfolgerungen ziehen, Lösungen entwerfen und nicht experimentieren kann. Jeder Schreiner kann einen vollkommen akzeptablen Hocker herstellen, aber technische Kenntnisse sind erforderlich, um den Hocker optimal zu machen: leicht, zuverlässig, stabil, einfach und billig herzustellen. Ein technischer Ansatz ermöglicht es Ihnen, schnell und mit geringstem Aufwand das optimale Ergebnis zu erzielen. Leider ist in der Softwareentwicklung ein Engineering-Ansatz nicht immer möglich.
Oft ist das gewünschte Ergebnis sehr vage definiert, viele Faktoren, die die Architektur der Lösung erheblich beeinflussen, sind unklar oder gar nicht bekannt, und die Arbeit an der Implementierung der Lösung selbst kann schneller und billiger sein als die detaillierte Ausarbeitung ihrer Architektur. Dies ist einer der Gründe, warum der iterative Entwicklungsansatz so populär geworden ist. Manchmal sogar unermesslich.
Im schlimmsten Fall kann die Entwicklung der Architektur darauf hinauslaufen, dass jedes Entwicklungsteam dem Architekten lediglich eine Überprüfung einer Beschreibung dessen gibt, was er implementieren wird. In einer solchen Situation reduziert sich die Arbeit eines Architekten auf das Aussortieren. Und hier hast du nicht vergessen? Hast du das berücksichtigt? Und hier ist es falsch. Möchten Sie hier einen Index hinzufügen? Und so Iteration nach Iteration.
Es ist notwendig, das Unkraut zu jäten. Aber wie wird ein Garten aussehen, wenn Sie dies nur tun? Blumenbeete verdorren im Schatten von Obstbäumen, Erdbeeren und Karotten wechseln sich ab, und all dies wird von unzähligen Wegen durchquert, die den verfügbaren Platz verschwenden. Es ist schwierig, hier über Architektur zu sprechen.
Damit Architektur erscheint, muss ein Architekt mindestens die Arbeit eines Gärtners erledigen. Beeren und Gemüse sollten getrennt angebaut werden - die Struktur, und wo die Menschen am häufigsten hingehen, müssen Sie Wege legen - Verbindungen. Durch die Beobachtung der Einzelheiten kann der Architekt proaktiv handeln und die besonderen Merkmale, die während des Realisierungsprozesses entstehen, in einer einzigen Struktur organisieren und systematisieren. Wie bei der Landschaftsgestaltung kann ein Architekt den natürlichen Ablauf von Ereignissen gestalten, positive Trends verstärken und negative verhindern.
Und hier brauchen wir eine klare Definition der Architektur im Code. Datenschemata, Strukturen von Modulen und Diensten, deren API und Interaktionsregeln. Ohne diese Tools zu definieren, wird der Architekt entweder in einer Implementierungsüberprüfung stecken bleiben oder naiv hoffen, dass die Entwickler die in einigen Dokumenten beschriebenen Regeln wirklich befolgen, was natürlich nicht passieren wird.
Wenn es eine formale Darstellung der Architektur und der Regeln für ihre Änderungen gibt, kann dies bereits als evolutionärer Ansatz für die Entwicklung der Architektur bezeichnet werden. Und das ist nicht schlecht. Aber sollten wir uns darauf beschränken?
Ja, anfangs können die Anforderungen vage aussehen, die Faktoren können vage aussehen und das System selbst ist so komplex, dass es einfacher zu tun ist als zu entwerfen. Aber im Laufe der Zeit werden diese Dinge klar. Mit der praktischen Erfahrung in der Entwicklung der Architektur werden die Details der Organisation ihres Anwendungsbereichs immer klarer. Es wird deutlich, dass diese allgemeine Lösung auf fünf verschiedene Arten implementiert wird und dass Benutzer unter dieser Vielfalt leiden. Dass einige Dinge fehl am Platz sind und verschoben werden müssen, während andere bereits veraltet sind und durch neue Lösungen ersetzt werden, sodass sie entfernt werden müssen. Und neue Entwicklungen sehen nicht mehr so neu aus - und das und das haben wir bereits umgesetzt. Erinnerst du dich, wozu das alles geführt hat? Machen wir es gleich, damit wir es später nicht wiederholen müssen. Immerhin ist es in der Regel schneller als nötig, es sofort richtig zu machen.Aber das ist nur, wenn Sie wirklich wissen, wie man es richtig macht. Und mit der Erfahrung kommt oft ein solches Verständnis.
Gute Architektur ist nicht etwas, das von selbst gewachsen und dann ein wenig organisiert wurde, sondern etwas ganzheitliches, symmetrisches und organisches. Ein technischer Ansatz für die Entwicklung der Architektur ist möglich. Das Verstehen der Regeln und Muster kann einige Zeit dauern.
Die formale Definition der Architektur eines bestimmten Projekts muss nicht statisch sein. Veraltete API-Methoden können als veraltet deklariert werden, und fehlende Methoden können als nicht implementiert deklariert werden. Die aussagekräftigen Teile des Codes können für die Platzierung in separaten Modulen markiert werden. Sie können planen, die Tabelle in zwei Teile zu teilen oder sie in eine andere Datenbank zu verschieben. Usw. Die Architektur kann geändert werden, ohne die Implementierung zu ändern. Die Umsetzung wird aufholen. Und um schneller aufzuholen, kann der Prozess leicht automatisiert werden, indem automatische Erinnerungen in Team-Chats vorgenommen werden. Auf die gleiche Weise können Änderungen, die von Entwicklern an Architekturdateien vorgenommen wurden, automatisch in den Chat des Architekturteams übernommen werden.
Ein technischer Ansatz zur Entwicklung der Architektur ist möglich.
Gleichzeitig sollte man nicht davon ausgehen, dass die Arbeit des Architekten grundlegend besser oder schlechter ist als die Arbeit des Entwicklers. Sie ist einfach anders. Der Entwickler arbeitet zunächst im imperativen Stil, während die Arbeit des Architekten deklarativer ist. Es kommt vor, dass es schwierig ist, die Architektur zu erarbeiten, aber die Implementierung ist eine Routine. Es passiert auch umgekehrt.
Architektur und Design
Die Begriffe Architektur und Design werden häufig synonym verwendet. Sie können sagen: Systemarchitektur oder Systemdesign. Im Großen und Ganzen ist klar, worum es geht. Es gibt jedoch signifikante Unterschiede in diesen Begriffen.
Design bedeutet vor allem etwas Visuelles, etwas, das man sich vorstellen oder sehen kann. Schemata, Diagramme, Modelle. Mit Design können Sie die Beziehung zwischen Entitäten visuell darstellen, Interaktionsketten verfolgen, strukturelle Unterschiede und Analogien erkennen.
Architektur ist jedoch nicht nur visuell, sondern kann auch Regeln und Einschränkungen, Schlussfolgerungen und mathematische Berechnungen enthalten. Konzepte, die schlecht visualisiert sind.
Natürlich sind beide wichtig.
Es ist gut, wenn wichtige Aspekte der Architektur im Code explizit definiert sind. Das reicht aber nicht. Es ist wichtig, die Architektur und die damit verbundenen Prinzipien automatisch zu gestalten.
Wenn die Architektur ein Datenschema enthält, muss es visuell dargestellt werden. Module haben Abhängigkeiten - sie müssen auch gerendert werden. Wenn es eine API gibt, sollte eine Dokumentation vorhanden sein, die in direktem Zusammenhang mit der Struktur der Dienste steht. Usw. Design ist eine visuelle Darstellung der Architektur.
Wenn die Architektur bestimmte Prinzipien hat, z. B. "Clientanwendungen können nur auf bestimmte Arten von Mikrodiensten zugreifen, aber nicht auf alle", können sie bei einem Kommunikationsmodell automatisch überprüft werden. Ebenso können Sie die Verknüpfungen zwischen Microservices und Datenbanken steuern. Wenn es bestimmte Regeln für den Entwurf von Datenmodellen gibt, dieselben Regeln für die Benennung von Tabellen, können diese auch automatisch überprüft werden. In der Entwicklung werden automatische Codeprüfungen verwendet, dies gilt auch für die Architektur. Sie können Autotests für Architektur schreiben.
Fazit
Der moderne Entwickler verfügt über eine Vielzahl erstaunlicher Tools, die ihm die Arbeit erleichtern. Entwicklungsumgebungen, Build-Systeme, verschiedene Bibliotheken und Frameworks, Infrastrukturdienste und Container. Entwickler schreiben keinen Code in Notepad.
Die Architektur ist auch Code, und für die Arbeit mit der Architektur gibt es ein Toolkit, das genauso leistungsfähig und umfangreich ist wie für die Arbeit mit der Implementierung. Google Text & Tabellen ist nicht das einzige Architekturwerkzeug, das Sie verwenden können, und es ist alles andere als das Beste. Natürlich ist die Auswahl an vorgefertigten Werkzeugen, die einem Architekten derzeit zur Verfügung stehen, bei weitem nicht so groß wie die Auswahl an Entwicklertools. Und nicht alles, was ein Architekt möglicherweise verwenden kann, funktioniert sofort. Trotzdem sind die Dinge nicht so schlecht.
Viele Tools gibt es schon seit Jahrzehnten, wie z. B. SQL. Sie müssen nur lernen, wie man sie richtig verwendet. Neue Technologien wie GraphQL gewinnen zunehmend an Bedeutung und lassen hoffen, dass die Beschreibung einer Geschäftsdomäne im Laufe der Zeit genauso routinemäßig wird wie die Beschreibung einer Speicherdomäne. Es stehen Tools zur Dokumentation und Visualisierung der Anwendungsstruktur und der API zur Verfügung, einschließlich Swagger. Sie können zum Testen der Architektur dieselben Frameworks und Integrationstools verwenden wie zum Testen der Implementierung.
Architektur - deklarativ. Wahrscheinlich wird die Bürokratie der Arbeit mit Dokumenten nie vollständig aus der Arbeit eines Architekten verschwinden, aber bereits jetzt kann ihr Volumen erheblich reduziert werden. Architektur ist auch Code, und im Laufe der Zeit können die verfügbaren Tools für die Arbeit an der Architektur so fortschrittlich werden wie die Tools für die Arbeit an der Implementierung. Wir werden sehen.
-
Dmitry Mamonov,
Wrike
PS Ich habe den Artikel mit einer Liste philosophischer Fragen begonnen, auf die ich hoffentlich ganz konkrete Antworten geben konnte. Zumindest ist das mein Standpunkt. Haben Sie in dem Artikel etwas Nützliches oder Neues gefunden? Wie beantworten Sie diese Fragen selbst? Schreiben Sie in die Kommentare.