effiziente Codestruktur

Als technische Lösung zur Lösung komplexer Geschäftsarchitekturen bieten Microservices theoretisch die Möglichkeit zur schnellen Iteration von Geschäftsprojekten. Obwohl die Kopplung zwischen Unternehmen in Bezug auf die Geschäftsentwicklung verringert wurde, kann die Entwicklungseffizienz verbessert werden, indem in verschiedene Fachleute investiert wird, um die Effizienz der Zusammenarbeit zu verbessern, aber es gibt noch eine wichtigere Sache, die die Entwicklungseffizienz beeinflusst, nämlich die Struktur des Codes Professioneller Diskurs ist Code-Architektur, eine gute Code-Architektur kann die menschliche Effizienz verbessern, und Microservice-Architektur kann die Team-Effizienz verbessern.

Welche Art von Codestruktur kann also als effizient angesehen werden, ich persönlich denke, dass es die folgenden Punkte gibt:

Die Geschäftsfunktionen sind geschichtet, und die Geschäftslogik des Codes ist klar geschichtet.

Die Codierung sollte auf realistischer Logik basieren, und die Logik der Geschäftsiteration sollte mit der Codestruktur und der hierarchischen Logik konsistent sein

Betrachten Sie die Bedürfnisse aus einer sich ändernden Perspektive und passen Sie sich an veränderte Benutzerbedürfnisse an

Vervollständigen Sie den Aufbau einer effizienten Codearchitektur

Schnittstellenplanung

Jeder Dienst befasst sich mit einer Geschäftsdomänenbeziehung, und die von dieser Domäne bereitgestellten Fähigkeiten und die Probleme, die sie löst, werden alle extern über Schnittstellen implementiert. Was ist dann die Iterationsregel der Schnittstelle, einschließlich der Aktualisierung der Versionsnummer und der Bereitstellung von Kernfunktionen, die im Voraus formuliert werden müssen.

Das Prinzip der Bereitstellung von Schnittstellen mit wichtigen Kernfunktionen besteht darin, sicherzustellen, dass sie sich so wenig wie möglich ändern

Einige Schlüsselfunktionen müssen aktualisiert werden, um den Kompatibilitätsmodus zu übernehmen oder die Version zu aktualisieren

Die Regeln für die Aktualisierung der Versionsnummer werden dadurch bestimmt, dass die entsprechende Version unterschiedliche Geschäftsspezifikationen, unterschiedliche Geschäftsprozesse usw. hat.

Kontextplanung

Für jeden Dienstcode benötigt die Logik in der Geschäftsdomäne, mit der sie sich befasst, einen Kontext für die Verarbeitung der Geschäftsassoziationslogik. Der Kontext ist die Verbindung zwischen dem Vorhergehenden und dem Nächsten, zu wissen, was sich im Upstream befindet, und dann den Downstream was tun zu lassen. Erst dann kann die Geschäftslogik vervollständigt werden. Teil des Kontextes ist die Übernahme der Verantwortung für die Schnittstellenplanung. Aber die Definition von Kontext übernimmt auch einen anderen Teil der Verantwortung in unserer Programmierung, die Wartbarkeit von Codierung. Ein gut gestalteter Kontext ist sehr hilfreich für die Zerlegung und Kombination und Wiederverwendung von Geschäftsmodulen und kann auch die Entwicklungseffizienz einer einzelnen Person für die gemeinsame Entwicklung desselben Geschäftsmoduls durch mehrere Personen verbessern. Die Kontextplanung umfasst nicht nur den Teil der Schnittstellenplanung, sondern umfasst auch die Planung der Kontextdefinition zwischen Schichten, nachdem das Geschäftsmodul geschichtet wurde.

Gestalten Sie den vollständigen und objektiven Informationsgehalt, der erforderlich ist, um Vergangenheit und Zukunft miteinander zu verbinden. Zum Beispiel umfasst der Kauf Produktinformationen, Preisinformationen und Lieferadressen

Die Kontextinformationen müssen auf den Bedürfnissen der Menschen basieren oder der Benutzer muss absolut darauf achten.Wenn sie die Anforderungen nicht erfüllen, erfüllen sie die Anforderungen nicht.Wenn sich herausstellt, dass die Informationen, die den Benutzer interessieren, dies nicht sind in der Definition enthalten, dann fehlt es.

Schichtarchitektur

Ein einzelner Microservice übernimmt mehrere Schichten der Geschäftsfähigkeitsschicht (Feign), der Geschäftsverarbeitungsschicht (Service), der Datenstrukturschicht (DAO, Client) und dann einige Dienste, die DDD als domänengesteuertes Design verwenden. Modell). Im Allgemeinen sind dies die Kategorien.Im Allgemeinen gibt es einige Dinge, die keine Domänenschicht haben.Es kann sein, dass die domänenbezogenen Fähigkeiten auf die Geschäftsverarbeitungsschichtund die Fähigkeitsschicht verteilt sind. Wenn Sie wirklich nah an der Programmierung der Anzeigelogik sein möchten, benötigen Sie immer noch eine Domänenschicht. Die Aufteilung ist nach der Namensgebung bekannt, im Folgenden werden die Verantwortlichkeiten dieser verschiedenen Ebenen kurz beschrieben.

Die Geschäftsfähigkeitsschicht, die Fähigkeit, externe Dienste bereitzustellen, kann verschiedene Szenenverarbeitungslogiken, Parametervorverarbeitung und -verifizierung umfassen, die Geschäftsschicht oder Domänenschicht aufrufen und das Ergebnis zurückgeben

Domänenschicht, jedes Objekt ist alle möglichen Geschäftsverarbeitungsoperationen eines Objekts in dieser Domäne und ruft Geschäftslogikverarbeitung auf

Die Business-Processing-Schicht dient der Verarbeitung von geschäftsbezogenen logischen Daten und bildet aufgrund der Datenstruktur nicht direkt das Geschäft ab, sondern nur die Verarbeitung von Datenänderungslogik, Ergänzung, Löschung, Änderung, Abfrage etc. und sollten keine Geschäftsmerkmale widerspiegeln.

Die Datenstrukturschicht, dies ist das Geschäftsarchitekturdesign, die Geschäftsanalyse und dann das durch Modellierung generierte Ausgabeergebnissystem.Es ist die zugrunde liegende Datenpräsentation und das Medium für den geschäftlichen Zugriff auf Produkte.

Saubere Architektur - Designprinzipien befolgen

Saubere Architektur (Clean Architecture) und sauberer Code (CleanCode) werden im Internetzeitalter befürwortet und stellen nur ein Ziel oder eine ideale Umsetzung für unser Softwaredesign dar. Ob es sich um eine saubere Architektur oder einen sauberen Code handelt, es ist sauber, und seine Logik und Implementierung sind für Benutzer oder Benutzer sowohl einfach als auch einfach, und es ist perfekt, um die Logik zu realisieren, mit der die meisten Menschen Dinge betrachten. Das heißt, es ist realitätsnah, reale Angelegenheiten ändern sich, und auch Code und Architektur können sich an Änderungen anpassen. Unabhängig davon, ob der Code sauber ist oder die Struktur sauber ist, halte ich persönlich die sechs Prinzipien des Softwaredesigns für wesentlich.

Softwaresystem-Metapher:

Jede Klasse ist ein Arbeiter, der Inhalt der Arbeit des Arbeiters ist die Codelogik, und die Fähigkeit ist die Methode der Klasse. Die Fähigkeit des Arbeiters kann anderen Arbeitern gegeben und beigebracht werden, und der Arbeiter muss auch kooperieren. Der Gesamtmanager Er selbst ist auch ein Arbeiter, aber seine Verantwortung besteht darin, andere Arbeiter zu koordinieren

Einzelverantwortung, die Verantwortung jedes Arbeiters muss einzeln sein, damit die eigene Wahrnehmung der Arbeiter klar und aufrechterhalten werden kann

Schnittstellenisolierung, es kann auch eine Klasse von Arbeitern geben, die dasselbe erreichen, aber die Methode ist anders, also muss sie klassifiziert werden, dies dient der Definition der Schnittstelle, nicht zu verwechseln

Richter Ersatz, ob die Pflichten eines Arbeitnehmers leicht ersetzt werden können, dies ist zu beurteilen, ob dieser Grundsatz verletzt wird

Das Prinzip des Öffnens und Schließens: Zu diesem Zeitpunkt muss man bedenken, dass diese Arbeiter keine Lernfähigkeit haben, aber es ist schwierig für sie, die von ihnen gebildeten Gewohnheiten zu ändern, und es ist leicht, danach Fehler zu machen Daher kann er nur neue Fähigkeiten erlernen und die alten nicht modifizieren.

Abhängigkeitsumkehrung, das bedeutet, dass sich mehrere Arbeiter koordinieren und zusammenarbeiten müssen Einige Arbeiter werden verwaltet, sodass die Person, die sie verwaltet, nicht mehr von ihm kontrolliert werden kann, da sonst die Reihenfolge chaotisch und die Szene nicht einheitlich ist.

Dimits Gesetz besagt, dass die Verantwortlichkeiten der Unternehmensleitung oder der Arbeitnehmer unabhängig sind. Wenn es Informationen zu kommunizieren gibt, dann werden die Informationen leicht durchgesickert und unsicher. Je weniger Arbeitnehmer voneinander wissen, desto besser.

Zusammenfassen

Basierend auf dem Obigen ist es in der Anwendung notwendig, Klassen und Instanzobjekte vernünftig wiederzuverwenden und vernünftig zu planen. Um eine gute Codestruktur zu vervollständigen. Führen Sie hauptsächlich architektonische Schichten und Geschäftssegmentierungen durch, übernehmen Sie Designprinzipien rational, um Objekte zu entwerfen, und verstehen Sie Designzwecke und Designideen.

Effiziente Codearchitektur für Microservices