[JAVA] Dinge, über die Sie nachdenken sollten, wenn Sie sich für die Architektur eines neuen Systems entscheiden

Zunaechst

Mein Name ist @kazuis und ich bin Ingenieur bei LITALICO Co., Ltd. Ich bin hauptsächlich verantwortlich für das von LITALICO bereitgestellte Unternehmenssystem für Sozialdienste für Menschen mit Behinderungen.

Dieser Artikel ist der Artikel zum 13. Tag von "LITALICO Adventskalender 2017".

Beim Erstellen eines neuen Systems fragen Sie sich möglicherweise, welche Sprache, Mitte und Methode Sie verwenden sollen. Eine coole Zusammenfassung des Prozesses zur Bestimmung der Architektur eines Systems macht wenig Sinn. Selbst im Wasserfall gibt es viele Methoden wie Scram und Designbücher. Und Sprach- und Middleware-Informationen sind im Internet überfüllt.

Es scheint jedoch wenig Informationen über die wichtigsten Punkte für die Auswahl der Architektur während dieser Zeit zu geben.

Ich werde es kurz zusammenfassen, um meine Gedanken zu organisieren.

Die geeignete Architektur sollte für jede Organisation und jedes Projekt unterschiedlich sein. Ich möchte über den Ansatz schreiben, für jede Person und jedes Unternehmen das "genau Richtige" zu finden.

Wenn Sie sich für einen großen Bereich mit der Systemarchitektur entscheiden, ist das Schreiben schwierig Dieses Mal werde ich nur die Elemente schreiben, die sich auf die Sprache und das Framework beziehen.

Informationen, die Sie bei der Entscheidung sammeln möchten

Die Architektur eines Systems hängt stark davon ab, "warum Sie ein System benötigen". Ist es, um es etwas übertrieben auszudrücken, ein Bankensystem oder ein Minispiel für einen Veranstaltungsort? Sie müssen nicht dieselbe Architektur haben.

Zunächst müssen Sie wissen, warum Sie ein System erstellen möchten.

Wenn Sie diese sammeln, verstehen Sie die Anforderungen an das System. Und Sie müssen wissen, was zu machen ist.

Es ist auch wichtig, die gleichen Geschäftsabläufe und funktionalen Anforderungen zu haben. Das Wichtigste ist, das "Konzept zu kennen, das Sie schätzen möchten".

Wenn die Kerndomäne nicht über die richtige Architektur verfügt Ich weiß nicht, wofür das System ist. Ich denke, dass es oft klar als System für Benutzer definiert ist, aber ich denke, dass es nur wenige Unternehmenssysteme gibt.

Danach benötigen Sie die Informationen, mit denen Sie normalerweise die Anforderungen analysiert haben. Wenn der Grund für den Aufbau eines neuen Systems systematisch ist, vor den Systemanforderungen Bis zu einem gewissen Grad möchte ich die Sprache oder die Infrastrukturinfrastruktur in die Cloud ändern Ich denke, es ist oft das Ziel, die Architektur zu ändern.

Erstens ist der Geschäftsfluss zu schnell und es ist schwierig zu entscheiden, bevor mit der Systementwicklung fortgefahren wird. Es kann eine schwierige Zeit sein. Hier denke ich, dass es ausreicht, anhand der Anforderungen zu bestimmen, ob fortzufahren ist, oder Feedback zu priorisieren.

Beispiele aus geschäftlichen Gründen

Ich möchte eine Funktion zur Entwicklung neuer Vertriebskanäle und Produkte. Vorerst möchte ich ein System, weil ich XXX (Geschwindigkeit) machen möchte. Ich möchte die Arbeitseffizienz erheblich verbessern.

Beispiele für systematische Gründe

Das System ist aufgebläht und kann mit der Geschäftsausweitung nicht mehr Schritt halten. Ich habe technische Schulden angehäuft und möchte sie zurückgeben. Die verwendete Technologie ist zu alt, um gewartet und weiterentwickelt zu werden. Die Wartungskosten sind aufgebläht, daher möchte ich die Effizienz verbessern.

Beispiele für technische strategische Gründe

In Zukunft möchte ich XXX machen Es gibt einen Unterschied zwischen der Umsetzung der Systemstrategie und dem aktuellen System.

Erstellen Sie aus den gesammelten Informationen eine Systemstrategie

Sobald die Informationen gesammelt sind, müssen Sie im nächsten Schritt entscheiden, wie das Problem gelöst werden soll. Gleiches gilt auch dann, wenn es keine sogenannte Anforderungsdefinition gibt. Hören und fühlen Sie die Temperatur, um ein ungefähres Gefühl zu erhalten.

Es ist in Begriffen organisiert, die häufig in Geschäftsbüchern wie Personen, Waren, Geld, Informationen und Zeit zu finden sind. Ich denke, dass das Ausmaß der Veränderungen im Geschäft, die Kosten und die Einstellung von Entwicklern wichtige Überlegungen sind.

Als Ergebnis der Berücksichtigung dieser Art von Elementen werden wir eine Systemstrategie entwickeln.

Einstufung Artikel Dinge zu denken
Mann Größe des Entwicklerteams Kann es von einer Person oder 100 Personen gemacht werden?
Mann Entwicklerteamfähigkeiten Kann das Entwicklungsteam es schaffen? Kann es gewartet werden?
Mann Einfaches Sammeln von Entwicklern Ist es einfach, Leute durch Einstellung anzuziehen?
Mono Gibt es eine Infrastrukturbeschränkung? Ich möchte die Cloud nutzen, kann es aber manchmal nicht.
Mono Anzahl der Geschäftsbetriebe, Benutzerskala wie Personen usw. Wie viel Rücksicht sollte auf die Einleitung genommen werden
Mono Zusammenarbeit mit dem bestehenden System Migration ist wichtig.
Mono Zusammenarbeit mit externem System Kennen Sie die Grenzen Ihres Systems.
Geld Budget Wenn das Ideal zu viel kostet, ist es möglicherweise nicht möglich.
Geld Geschäftsmaßstab und seine Prognose Systematisieren Sie unter Berücksichtigung der Datenmenge und der Informationsmenge
Information Modellbeziehung Die Domänenaufteilung kann die Systemaufteilung sein.
Information Menge an Informationen Sollte eine Datenaufteilung in Betracht gezogen werden?
Information Die Geschwindigkeit, mit der sich Informationen ändern Wenn Sie die Geschwindigkeit des Geschäftswechsels nicht kennen
Information Anzahl der geschäftskritischen Aufgaben Geschäftssystem mit viel Rechenaufwand
Information セキュリティが必要なInformation Wie viele wichtige Informationen sind vorhanden, z. B. persönliche Informationen?
Zeit 初期リリースまでのZeit Der Entwicklungsprozess kann sich während der ersten Veröffentlichung und des ersten Betriebs ändern
Zeit Häufigkeit der Anfragen Wie oft fordern Sie Systemänderungen an?
Zeit Systemlebenszyklus Ist eine Betriebsdauer von 10 Jahren geplant? Ist es zwei Jahre?

Bestimmen Sie zunächst den Umfang des Systems.

Bestimmen Sie dann die Klassifizierung des Zielsystems. Es wird klassifiziert, ob es sich um SoR (System of Record) oder SoE (System of Engagement) handelt.

SoR ist ein System, das die korrekte Aufzeichnung von Transaktionen und Buchhaltungsinformationen erfordert.
SoE ist ein System, das für jeden Benutzer optimiert werden muss, z. B. Meine Seite, das hauptsächlich von Benutzern verwendet wird.

Wenn es sich um ein SoR-ähnliches System handelt, sollten Sie überlegen, ob Sie eine solide Architektur auswählen möchten. Wenn es sich um ein SoE-ähnliches System handelt, sollten Sie eine Architektur und einen Entwicklungsprozess in Betracht ziehen, die mit einem Gefühl der Geschwindigkeit entwickelt werden können.

Ich denke, dass dies für jedes Subsystem unterschiedlich sein kann. Wenn Sie eine Mikrodienstarchitektur verwenden, ist dies eine andere Sache.

Nach der Entscheidung über die Klassifizierung war es für den Lebenszyklus geeignet Bestimmen Sie eine Systemstrukturstrategie, die die ursprünglichen Anforderungen erfüllt

Wenn es sich um ein SoR-ähnliches System handelt, kann meines Erachtens ein monolithisches System verwendet werden, solange der Maßstab nicht zunimmt. Microservices sind schwierig zu gestalten. Erwägen Sie die Erstellung einer Struktur, die Datenintegrität erfordert.

Wenn es sich um ein SoE-ähnliches System handelt, sollten nach der ersten Version viele Systemänderungsanforderungen vorliegen. Entscheiden Sie, dass die Architekturstruktur selbst auch eine Struktur sein soll, die hinzugefügt werden muss.

Dinge, über die Sie nachdenken sollten, wenn Sie sich für eine Sprache oder ein Framework entscheiden

Sobald Sie die Struktur des Systems kennen, entscheiden Sie, welche Entwicklungssprache sich darin verhält. Ist Java am häufigsten beim Erstellen von Unternehmenssystemen? Es scheint, dass die Lieblingssprachen und Frameworks der Ingenieure in Startups wie Ventures verwendet werden.

Für SoR-ähnliche Systeme bevorzuge ich eine solide Sprache und ein solides Framework, daher ist Java eine gute Wahl. Obwohl Systemänderungsanforderungen selten sind, gibt es regelmäßige Änderungsanforderungen. Die Lernkosten sind etwas hoch, aber es gibt viele gute Dinge, bei denen die Strukturänderung als Erstellungsfehler erkannt werden kann, wenn es einen Typ gibt. Ich denke, es ist geeignet, um die Struktur und den Zustand zu kontrollieren.

Im Fall eines SoE-ähnlichen Systems gibt es viele Anforderungen an Änderungen des Geschäftsflusses und der Benutzerfreundlichkeit, daher ist Geschwindigkeit erforderlich. Ich mag die Sprache und das Framework, die repariert und überprüft werden können. Ich denke, es ist gut, einen Mechanismus zu erstellen, mit dem Sie erstellen können, während Sie Feedback zu Ruby und PHP erhalten. Selbst Unternehmenssysteme müssen in der Lage sein, den Bedarf an Geschwindigkeit wie Webdienste zu decken.

Gemeinsame und wichtige Dinge

Natürlich können Sie die Funktionalität bei der Auswahl einer Sprache oder eines Frameworks erreichen. Die folgenden drei sind die wichtigsten.

Unabhängig davon, welche Art von System Sie herstellen, ist es bedeutungslos, es sei denn, Sie können es bedienen und warten. Es gibt auch einen Trend bei Frameworks. Das Framework, das Sie während der Entwicklung ausgewählt haben, wird möglicherweise fünf Jahre später in Erinnerung bleiben.

Daher ist es nicht möglich, eine Sprache oder ein Framework auszuwählen, die den technischen Ablauf ignoriert. Es ist notwendig, eine Wahl zu treffen, die keinen Fehler im technischen Ablauf macht, nicht in der Mode.

Das Framework ist möglicherweise veraltet, aber Sie müssen Entscheidungen treffen, um die Fähigkeiten Ihrer Ingenieure zu verbessern. Mit zunehmendem Kenntnisstand des Ingenieurs bleibt das System funktionsfähig und kann problemlos wiederhergestellt werden. Und Ingenieure, die ein technisches Flow-Framework verwenden möchten, können zusammenkommen. (Ingenieure mögen keine alten Frameworks ... neue Frameworks motivieren)

Ich denke, dass es in den letzten Jahren auch einen solchen Aspekt gibt, dass der Name Scala durch die Neugestaltung eines großen Systems hervorgehoben wird. (Ich mag Scala!)

Sie sind auch für die Fertigstellung und den Betrieb des Systems verantwortlich. Wie man das ausbalanciert, zeigt das Können des Architekten.

Schließlich

Selbst für Unternehmenssysteme ist der Geschäftsfluss schnell. Selbst wenn Sie sich in einem frühen Entwicklungsstadium für eine Architektur entscheiden, ist diese im Lebenszyklus des Systems nicht immer korrekt.

Im Bereich der Wohlfahrt für Menschen mit Behinderungen, der von Ritalico betrieben wird, ist es schwierig, das System zu unterstützen, da sich das nationale System noch im Wandel befindet.

Wir streben eine Architektur an, die leicht zu brechen ist und im Detail neu erstellt werden kann.

Recommended Posts

Dinge, über die Sie nachdenken sollten, wenn Sie sich für die Architektur eines neuen Systems entscheiden
Wie man über Klassengestaltung (Division) in einem Geschäftssystem nachdenkt (1)
Dinge, auf die Sie beim Erstellen eines Frameworks achten sollten
Wie man denkt, wenn man plötzlich etwas über Generika versteht
Beachten Sie beim Upgrade von Tomcat auf einem Web-System, das Oracle verwendet
Ein Hinweis, als ich süchtig danach war, Ubuntu auf WSL1 in WSL2 zu konvertieren
Dinge, die beim Ausführen eines bestimmten Jobs mit Spring Batch zu beachten sind
Dinge, die Sie beim Abfangen einer Anfrage mit Android WebView vergessen sollten # shouldInterceptRequest
Denken bei der Einführung einer neuen Bibliothek
Wechseln Sie in einem neuen Ruby on Rails-Projekt von SQLite3 zu PostgreSQL
So geben Sie registrierten Daten beim Hinzufügen eines neuen Datensatzes die MAX + 1-ID
Was ist zu tun, wenn auf den Schienen cHoge.connection aufruft, um eine Verbindung herzustellen? C.
Hinweise zur Vorgehensweise beim Auftreten einer WebView ClassNotFoundException in JavaFX 12