Kurz gesagt: Was muss ein Architekt tun?

Dieser Artikel ist eine Kurzgeschichte, die Fragen und Antworten imitiert, und der Autor verwendet einen humorvollen Stil, um die Arbeit von Architekten kurz zu analysieren: Ich möchte Softwarearchitekt werden.

Das ist eine großartige Option für junge Softwareentwickler.

Ich möchte das Team führen und wichtige Entscheidungen zu Datenbanken und Frameworks, Webservern usw. treffen.

Oh, dann willst du gar kein Softwarearchitekt sein.

Natürlich wollte ich selbst wichtige Entscheidungen treffen.

Das ist in Ordnung, aber du nimmst keine wichtigen Entscheidungen in deine Liste auf, die irrelevant sind.

Was meinst du? Willst du sagen, dass Datenbanken keine wichtigen Entscheidungen sind, weißt du, wie viel wir dafür ausgeben?

Vielleicht kostet es zu viel. Datenbanken gehören jedoch nicht zu den wichtigen Entscheidungen.

Wie kannst du das sagen? Die Datenbank ist der Kern des Systems, in dem alle Daten systematisiert, klassifiziert, indexiert und abgerufen werden. Ohne eine Datenbank gäbe es kein System.

Die Datenbank ist nur ein IO-Gerät, das zufällig einige nützliche Werkzeuge für Klassifizierung, Abfragen und Informationsberichterstattung bereitstellt, aber dies sind nur Hilfsfunktionen der Systemarchitektur.

Hilfe? Das ist empörend.

Genau, es ist ein Hilfssystem. Die Geschäftsregeln des Systems können möglicherweise einige dieser Werkzeuge nutzen, aber diese Werkzeuge sind nicht inhärent in die entsprechenden Geschäftsregeln. Falls nötig, kannst du die vorhandenen durch andere Werkzeuge ersetzen; Und die Geschäftsregeln werden sich nicht ändern.

Nun, ja, aber es musste neu codiert werden, weil diese Werkzeuge in der ursprünglichen Datenbank verwendet wurden.

Das ist dein Problem.

Was meinst du?

Dein Problem ist, dass du denkst, Geschäftsregeln hängen von Datenbankwerkzeugen ab, aber das sind sie nicht. Oder zumindest sollte es nicht so sein, bis eine gute Architektur vorliegt.

Es ist einfach verrückt. Wie erstellt man Geschäftsregeln, die diese Tools nicht verwenden?

Ich sage nicht, dass sie keine Datenbankwerkzeuge verwenden, aber sie sind nicht darauf angewiesen. Business Rules müssen nicht wissen, welche Datenbank du nutzt.

Wie bekommt man also Geschäftsregeln, ohne zu wissen, welche Tools man verwenden muss?

Invertiere die Abhängigkeiten, sodass die Datenbank auf Geschäftsregeln basiert. Stellen Sie sicher, dass Geschäftsregeln nicht von der Datenbank abhängig sind.

Du redest Unsinn.

Im Gegenteil, ich benutze die Sprache der Softwarearchitektur. Dies ist das Prinzip der Abhängigkeitsinversion: Niedrigstufige Standards sollten auf hochstufige Standards setzen.

Unsinn! Hochrangige Kriterien (vorausgesetzt, sie beziehen sich auf Geschäftsregeln) Aufruf von niedrigen Kriterien (vorausgesetzt, es handelt sich um Datenbanken). Daher beruht das High-Level-Kriterium auf dem Low-Level-Kriterium gemäß dem Prinzip, dass der Anrufer vom Angerufenen abhängig ist. Das weiß jeder!

Das gilt zur Laufzeit. Aber beim Kompilieren wollen wir eine Abhängigkeitsinversion. Der Quellcode der High-Level-Richtlinien sollte den Quellcode der Low-Level-Richtlinien nicht erwähnen.

Komm schon! Wie kannst du einen Anruf tätigen, ohne es zu erwähnen?

Natürlich, kein Problem. Das ist es, worum objektorientiert geht.

Objektorientierung bezieht sich auf die Erstellung realer Modelle, bei der Daten, Funktionalität und kohärente Objekte kombiniert werden. Es geht darum, Code in eine intuitive Struktur zu organisieren.

So sagen sie?

Wie wir alle wissen, ist das die offensichtliche Wahrheit.

Ja, das ist es, aber bei der Verwendung objektorientierter Richtlinien ist es tatsächlich möglich, ohne es zu erwähnen aufzurufen.

Wie macht man das?

Im objektorientierten Design senden Objekte Nachrichten zueinander.

Das stimmt natürlich.

Wenn ein Absender eine Nachricht sendet, weiß er nicht, um welchen Empfänger es sich handelt.

Es hängt von der verwendeten Sprache ab. In Java kennt der Absender mindestens den Grundtyp des Empfängers. In Ruby weiß der Absender zumindest, dass der Empfänger in der Lage ist, die empfangenen Nachrichten zu verarbeiten.

Das stimmt. In jedem Fall kennt der Sender jedoch nicht den genauen Empfängertyp.

Genau, nun, das ist es.

Daher kann ein Sender einen Empfänger so entwerfen, dass er eine Funktion ausführt, ohne den spezifischen Empfängertyp zu erwähnen.

Genau, genau. Ich verstehe. Der Absender hängt jedoch weiterhin vom Empfänger ab.

Das gilt zur Laufzeit. Allerdings ist es beim Kompilieren anders. Der Quellcode des Absenders erwähnt oder hängt nicht von dem Quellcode des Empfängers ab. Tatsächlich hängt der Quellcode des Empfängers vom Quellcode des Absenders ab.

Auf keinen Fall! Der Absender hängt weiterhin von der gesendeten Klasse ab.

Vielleicht wird es aus einem Quellcode klarer. Der folgende Absatz ist in Java verfasst. Zuerst der Absender:

Hier ist der Empfänger:

Hinweis: Empfänger hängt vom Sender ab, SpecificReceiver vom Sender, und es gibt keine empfängerbezogene Informationen im Sender.

Ja, aber du lügst, du hast die Empfänger-Schnittstelle in die Sender-Klasse gesetzt.

Du fängst an, es zu verstehen.

Was weißt du schon?

Natürlich ist es das Prinzip der Architektur. Der Sender hat die Schnittstelle, die der Empfänger implementieren muss.

Wenn das bedeutet, dass ich verschachtelte Klassen verwenden muss, dann ......

Verschachtelte Klassen sind nur eines der Mittel zum Zweck, es gibt auch andere Wege.

Warte mal. Was hat das mit Datenbanken zu tun? Wir haben angefangen, über Datenbanken zu sprechen.

Schauen wir uns den Code noch einmal genauer an. Die erste ist eine einfache Geschäftsregel:

Geschäftsregeln haben nicht viel Gewicht.

Das ist nur ein Beispiel. Es könnte mehr solcher Klassen geben, die viele verschiedene Geschäftsregeln implementieren.

Okay, was genau ist Gateway?

Es stellt alle Datenzugriffsmethoden über Geschäftsregeln bereit. Implementieren Sie es wie folgt:

Hinweis: Dies befindet sich in businessRules.

Okay, was ist die Etwas-Klasse?

Es stellt ein einfaches Geschäftsobjekt dar. Ich habe es in Entitäten eingeordnet.

Letztlich kennt die Implementierung von BusinessRuleGateway, diese Klasse, die echte Datenbank:

Außerdem ist zu beachten, dass die Geschäftsregeln die Datenbank zur Laufzeit aufrufen; Beim Kompilieren beinhaltet und hängt die Datenbank jedoch von businessRules ab.

Nun, ich glaube, ich verstehe es. Du verwendest einfach Polymorphismus, um zu verbergen, dass die Datenbank implementiert ist, aus Geschäftsregeln. Dennoch ist eine Schnittstelle erforderlich, um alle Datenbankwerkzeuge für die Geschäftsregeln bereitzustellen.

Nein, überhaupt nicht. Wir haben nicht versucht, Datenbankwerkzeuge für Geschäftsregeln bereitzustellen. Stattdessen verwenden sie Geschäftsregeln, um Schnittstellen für das zu erstellen, was sie brauchen. Die Implementierung dieser Schnittstellen ermöglicht es Ihnen, die richtigen Werkzeuge aufzurufen.

Ja, aber wenn du jedes Tool für alle Geschäftsregeln verwenden musst, dann setze das Tool einfach in die Gateway-Oberfläche.

Ah, ich glaube, du verstehst das noch nicht.

Was verstehen? Das ist bereits klar.

Jede Geschäftsregel definiert nur eine Schnittstelle für die benötigten Datenzugriffswerkzeuge.

Moment mal, was sagst du?

Das ist das Prinzip der Schnittstellentrennung. Jede Business-Regelklasse verwendet nur bestimmte Funktionen der Datenbank. Daher können die von jeder Geschäftsregel bereitgestellten Schnittstellen nur auf die entsprechenden Funktionen zugreifen.

Das bedeutet jedoch, dass es viele Schnittstellen und viele kleine Implementierungsklassen gibt, die andere Datenbankklassen aufrufen.

Super, du fängst an, es zu verstehen.

Aber es ist zu chaotisch und Zeitverschwendung. Warum machst du das?

Das ist organisiert und spart Zeit.

Komm schon, hol dir viel Code um des Codes willen.

Im Gegenteil, irrelevante Entscheidungen können durch wichtige architektonische Entscheidungen verzögert werden.

Was bedeutet das?

Ich erinnere mich, am Anfang hast du gesagt, du wolltest Softwarearchitekt werden, oder? Du willst alle wirklich wichtigen Entscheidungen treffen.

Ja, das dachte ich mir.

Sie wollen doch Entscheidungen über Datenbanken, Webserver und Frameworks treffen, richtig?

Ja, du sagst, dass das alles keine Rolle spielt. Nur irrelevante Inhalte.

Das stimmt. Das wars. Die wichtigen Entscheidungen von Softwarearchitekten sind diejenigen, die es Ihnen ermöglichen, Entscheidungen über Datenbanken, Webserver und Frameworks zu treffen.

Aber du musst erst entscheiden, welche!

Nein, es funktioniert nicht. Tatsächlich können diese später im Entwicklungszyklus entschieden werden, wenn die Informationen reichlicher vorhanden sind.

Es ist eine Katastrophe, wenn Architekten Rahmenwerke im Voraus identifizieren, nur um festzustellen, dass diese nicht die erforderliche Leistung liefern oder unerträgliche Einschränkungen einführen.

Erst wenn der Architekt sich entscheidet, die Entscheidung zu verschieben, trifft er eine Entscheidung, wenn die Informationen ausreichen; Teams, die keine langsamen und ressourcenintensiven IO-Geräte und -Frameworks verwenden, können nach Ermessen der Architekten schnelle, leichte Testumgebungen erstellen. Nur ihre Architekten kümmern sich darum, was wirklich zählt, und verzögern diejenigen, die es nicht tun, und ein solches Team ist das Glückliche.

Unsinn, ich verstehe überhaupt nicht, was du meinst.

Schau dir diesen Artikel genau an, sonst musst du noch weitere 10 Jahre warten, um es herauszufinden.