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.
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.
System Anforderungen
Ich persönlich mag die RDRA-Analysemethode, weil sie modellbasiert ist. Ich benutze es während des Studiums, weil es eine bessere Sicht auf das gesamte System aus der Perspektive der Bestimmung der Architektur gibt. Modellbasierte Anforderungsdefinitionstechnik Zenji Kanzaki
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.
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.
In Zukunft möchte ich XXX machen Es gibt einen Unterschied zwischen der Umsetzung der Systemstrategie und dem aktuellen System.
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.
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.
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.
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