Beratung zum Entwerfen von Webanwendungen mit einer Lebensdauer von über 40 Jahren

Szenario

Derzeit bin ich Teil eines Gesundheitsprojekts, dessen Hauptanforderung es ist, Daten mit unbekannten Attributen mithilfe von benutzerdefinierten Formularen von Gesundheitsdienstleistern zu erfassen. Die zweite Anforderung ist, dass die Datenintegrität der Schlüssel ist und dass die Anwendung über 40 Jahre lang verwendet wird. Derzeit migrieren wir die Kundendaten der letzten 40 Jahre aus verschiedenen Quellen (Papier, Excel, Access usw.) in die Datenbank. Zukünftige Anforderungen sind:

• Workflow-Management von Formularen
• Planen Sie die Verwaltung von Formularen
• Sicherheits- / rollenbasiertes Management
• Berichtsmodul
• Mobile / Tablet-Unterstützung

Lage

In nur 6 Monaten hat der derzeitige (beauftragte) Architekt / leitende Programmierer den "schnellen" Ansatz gewählt und ein schlechtes System entworfen. Die Datenbank ist nicht normalisiert, der Code ist gekoppelt, die Ebenen haben keinen bestimmten Zweck und Daten gehen allmählich verloren, da er einige Beans entworfen hat, um "Löschvorgänge" in der Datenbank durchzuführen. Die Codebasis ist extrem aufgebläht und es gibt Jobs, um nur Daten zu synchronisieren, da die Datenbank nicht normalisiert ist. Sein Ansatz war es, sich auf Sicherungsjobs zu verlassen, um fehlende Daten wiederherzustellen, und er scheint nicht an ein Re-Factoring zu glauben.

Der Architekt, der dem Ministerpräsidenten meine Ergebnisse vorgelegt hat, wird mit Ablauf seines Vertrages entlassen. Mir wurde die Aufgabe übertragen, diese Anwendung neu zu gestalten. Mein Team besteht aus mir und einem Junior-Programmierer. Wir haben keine anderen Ressourcen. Wir haben einen 6-monatigen Anforderungsstopp erhalten, in dem wir uns auf den Wiederaufbau dieses Systems konzentrieren können.

Ich schlug vor, ein CMS-System wie Drupal zu verwenden, aber aus politischen Gründen beim Kunden muss das System von Grund auf neu erstellt werden.

Dies ist das erste Mal, dass ich ein System mit einer Lebensdauer von über 40 Jahren entwerfe. Ich habe nur an Projekten mit einer Lebensdauer von 3-5 Jahren gearbeitet, daher ist diese Situation sehr neu und dennoch aufregend.

Fragen

• Welche konstruktiven Überlegungen machen das System "zukunftssicherer"?
• Welche Fragen sollten dem Kunden / PM gestellt werden, um das System "zukunftssicherer" zu machen?

Daten sind König

Ich halte es für etwas unvernünftig, zu erwarten, dass eine Webanwendung um 2013 im Jahr 2053 noch funktionsfähig ist. Die Technologien werden sich ändern. Plattformen werden kommen und gehen. Bis dahin könnte HTML eine kuriose Erinnerung sein. Aber Ihre Daten werden immer noch da sein.

Daten stehen also im Vordergrund. Solange Ihre Daten noch vorhanden sind, können sich die Mitarbeiter auf die neuen Technologien einstellen. Stellen Sie sicher, dass Ihre Datenschemata gut durchdacht und für die Erweiterung geeignet sind. Nehmen Sie sich Zeit, um sie herauszufinden.

In Bezug auf die tatsächlichen Anwendungen hat Ihr Unternehmen hier wahrscheinlich Recht, wenn es eine Direktive von Grund auf neu erstellt. Ich verwalte einige Web-Apps, die älter als 10 Jahre sind, und ich bin sehr froh, dass sie nicht an die vorherrschenden CMS-Systeme von 2003 gebunden sind. Sie verwenden einheimische, sehr einfache Frameworks. Ich denke für so etwas sind Sie besser dran mit einem sehr einfachen Framework, das Sie speziell für die Bedürfnisse des Projekts erstellen.

In Wirklichkeit wird das Unternehmen über 40 Jahre lang (hoffentlich) eine ganze Reihe von Front-End- und Back-End-Diensten bereitstellen, um sich an sich entwickelnde Plattformen anzupassen. Daher würde ich eine Lebensdauer von 5 bis 10 Jahren für einzelne benutzerbezogene Anwendungen anstreben.

Wir produzieren Software, die seit über 20 Jahren von zahlenden Kunden genutzt wird. Die Codebasis hat mehrere Generationen von Tools zur Versionskontrolle überlebt. Unsere Software trifft alle Ihre Aufzählungszeichen mit Ausnahme der Tabletsache.

Einige der Bedenken betreffen ESIGN und UETA . Unsere Anwälte glauben, dass wir elektronische Aufzeichnungen mindestens 10 Jahre lang lesbar halten müssen. Für Dokumente, die vollständig aufbewahrt werden, sollten Sie sich PDF / A ansehen .

Sorgen Sie sich für Ihre Datenbank nicht zu sehr um die Normalisierung. Stattdessen sollten Sie sich darum kümmern, alles zu protokollieren und Prüftabellen zu haben, die Änderungen / Löschungen in Daten verfolgen. Planen Sie beim Aktualisieren von Versionen das parallele Testen neuer Versionen für genügend Zeit ein, um sicherzustellen, dass Ihre Daten migriert werden. Dieses Testen neuer Versionen umfasst auch neue Betriebssysteme - wir hatten im Laufe der Jahre einige sehr unangenehme Überraschungen. Bewahren Sie Installationsmedien und Lizenzschlüssel für den Fall auf, dass ein Rollback durchgeführt werden muss. Backups testen. Wenn Sie Objekte serialisieren, die in der Datenbank gespeichert werden sollen, verwenden Sie XML anstelle der von Ihrem Entwicklungsframework bereitgestellten Serialisierung.

Für Ihre Besetzung benötigen langfristige Codebasen ein langfristiges Gedächtnis. Im Idealfall möchten Sie Menschen, die schon lange in der Nähe sind. Wenn das institutionell unmöglich ist, müssen Sie alles in so etwas wie einem Wiki dokumentieren. Mein Rat ist ein Wiki, das sich in Ihr Bug-Tracking-System einfügt.

Stellen Sie für Ihre Codebasis sicher, dass Sie Kommentare in Ihrem Code haben. Bei der Migration von einem Versionskontrollsystem auf ein anderes gehen fast immer Ihre Check-in-Kommentare verloren. Ich bin ein Fan von Benennungstests nach Spezifikations- und Fehlernummern. Auf diese Weise Test_Bug_1235 wissen Sie, was und wo Sie herausfinden können, was getestet werden soll, wenn der Komponententest unterbrochen wird. Es ist nicht so "sexy" wie das Benennen Ihrer Tests, Check_File_Save_Networked_Drivesaber diese Art von Test ist anders als bei Spezifikationen, Anforderungen oder Fehlern schwer zurückzuverfolgen Test_requirement_54321_case_2.

Anstatt herauszufinden, wie diese Anwendung in 20 Jahren noch funktioniert, sollten Sie sich ein halbes Jahr Zeit nehmen, um die vom ursprünglichen Architekten verursachten Probleme zu beheben und eine vernünftige, robuste Architektur einzurichten gehe von dort aus vorwärts

Eine teilweise De-Normalisierung einer Datenbank ist in einem medizinischen Umfeld nicht unbedingt völlig unerwartet. Einige Teile der medizinischen Datenbanken weisen Merkmale auf, die sie für das EAV- Modell (Entity / Attribute / Value) geeignet machen .

Antwort aus Front-End-Perspektive:

Hören Sie nicht zu, wie alle sagen, dass dies nicht möglich ist, da ein experimenteller Webdienst der San Francisco State University, den ich 1996 mitschrieb, vor ein paar Jahren endlich in den Internet-Himmel kam und in dieser Zeit keine einzige Browser-Kompatibilitätskorrektur benötigte ; Das ist fast die Hälfte Ihres 40-Jahres-Ziels. Und dieses JavaScript-basierte Front-End, das ich 1998 für ein Projekt des Stanford Research Institute erstellt habe, wurde ein paar Jahre später durch etwas auffälligeres ersetzt, aber es gibt keinen Grund, warum die ursprüngliche Benutzeroberfläche mit geringfügigen Kompatibilitätskorrekturen heute noch nicht ausgeführt werden konnte.

Der Trick besteht darin, sicherzustellen, dass Ihre App nur allgemein unterstützte W3C / ECMA-Standards verwendet und ein klares Design unter Ihrer Kontrolle hat. Während viele Web-Apps, die auf die trendige Technologie der 90er Jahre zugeschnitten sind, heute nicht mehr oder überhaupt nicht mehr funktionieren, sind es Web-Apps der 90er Jahre, die nach den wichtigsten Standards geschrieben wurden, immer noch. Sie mögen passé aussehen, aber sie funktionieren.

Hier geht es nicht darum, eine Web-App zu schreiben, die auf ihrem Server hochfährt und dort 40 Jahre bleibt, ohne dass jemand sie erneut berührt. Es geht darum, ein Fundament zu schaffen, das noch Jahrzehnte in Gebrauch sein kann und das wachsen kann, um neue Funktionen zu unterstützen, ohne dass es von Grund auf neu erstellt werden muss.

Zuallererst müssen Sie nach offiziellen Standards und nur nach offiziellen Standards codieren . Keine JavaScript-Funktionen, die nicht Teil eines ratifizierten ECMAScript-Standards sind. ES5.1 ist die aktuelle Version und wird im Allgemeinen unterstützt, sodass das Ziel sicher ist. Ebenso sind aktuelle Versionen von HTML5, CSS und Unicode gut. Keine experimentellen JavaScript-, CSS3- oder HTML-Funktionen (die mit Herstellerpräfixen oder ohne 100% ige Übereinstimmung zwischen den Browsern). Und keine browserspezifischen Kompatibilitätshacks. Sie können eine neue Funktion verwenden, sobald sie im Standard enthalten ist. Alle Benutzer unterstützen sie ohne Präfixe.

ES5-Unterstützung würde bedeuten, IE8 oder früher fallen zu lassen, was ich sowieso vorschlage, da es browserspezifische Hacks erfordert, die in ein paar Jahren unbrauchbar werden. Ich würde den Strikten Modus von ES5 vorschlagen, um die beste Langlebigkeitschance zu erzielen. Dadurch wird die Basiskompatibilität Ihres Browsers mit IE10 und den neuesten Versionen aller anderen festgelegt . Diese Browser bieten auch native Unterstützung für viele der HTML5-Funktionen zur Formularüberprüfung und Platzhalter, die sehr lange nützlich sein werden.

Neue Versionen von ECMAScript sind weiterhin mit älteren Versionen kompatibel. Daher ist es viel einfacher, zukünftige Funktionen zu übernehmen, wenn Ihr Code gemäß den aktuellen Standards geschrieben wurde. Beispielsweise können Klassen, die mit der bevorstehenden classSyntax definiert wurden , vollständig mit Klassen ausgetauscht werden, die mit der aktuellen constructor.prototypeSyntax definiert wurden. So kann ein Entwickler in fünf Jahren Klassen Datei für Datei in das ES6-Format umschreiben, ohne dass irgendetwas kaputt geht - vorausgesetzt natürlich, Sie haben auch gute Komponententests.

Zweitens sollten Sie trendige JavaScript-App-Frameworks vermeiden, insbesondere wenn sie die Art und Weise ändern, in der Sie Ihre App codieren. Backbone war der letzte Schrei, dann waren es SproutCore und Ember, und jetzt ist Angular das Framework, für das jeder gerne wirbt. Sie mögen nützlich sein, haben aber auch eines gemeinsam: Sie brechen häufig Apps und erfordern Codeänderungen, wenn neue Versionen herauskommen und ihre Langlebigkeit fraglich ist. Ich habe kürzlich eine Angular 1.1-App auf 1.2 aktualisiert und musste einiges umschreiben. Ebenso sind für den Wechsel von Backbone 2 zu 3 viele HTML-Änderungen erforderlich. Standards bewegen sich aus einem bestimmten Grund nur langsam, aber diese Frameworks bewegen sich schnell und Dinge, die regelmäßig kaputt gehen, sind die Kosten.

Außerdem machen neue offizielle Standards alte Frameworks häufig überholt. In diesem Fall mutieren diese Frameworks entweder (mit aktuellen Änderungen) oder bleiben zurück. Wissen Sie, was mit allen konkurrierenden Versprechenbibliotheken der Welt passieren wird, wenn ECMAScript 6 ratifiziert ist und alle Browser die standardisierte Versprechen-Klasse unterstützen? Sie sind veraltet und werden von ihren Entwicklern nicht mehr aktualisiert. Wenn Sie sich für das richtige Framework entschieden haben, passt sich Ihr Code möglicherweise gut an, und wenn Sie nicht sicher sind, ob es sich um eine größere Umgestaltung handelt.

Wenn Sie also daran denken, eine Bibliothek oder ein Framework von Drittanbietern zu übernehmen, fragen Sie sich, wie schwer es sein wird, diese in Zukunft zu entfernen. Wenn es sich um ein Framework wie Angular handelt, das niemals entfernt werden kann, ohne die App von Grund auf neu zu erstellen, ist dies ein gutes Zeichen dafür, dass es in einer 40-jährigen Architektur nicht verwendet werden kann. Wenn es sich um ein Kalender-Widget eines Drittanbieters handelt, das Sie mit einer benutzerdefinierten Middleware abstrahiert haben, dauert das Ersetzen einige Stunden.

Drittens geben Sie ihm eine gute, saubere App-Struktur. Auch wenn Sie kein App-Framework verwenden, können Sie Entwickler-Tools, Skripts und ein gutes, übersichtliches Design nutzen. Ich persönlich bin ein Fan des Abhängigkeitsmanagements von Closure Toolkit, da es leichtgewichtig ist und der Overhead beim Erstellen Ihrer App vollständig entfernt wird. LessCSS und SCSS eignen sich auch hervorragend zum Organisieren Ihrer Stylesheets und zum Erstellen standardbasierter CSS-Stylesheets für die Veröffentlichung.

Sie können Ihren eigenen Code auch in Einwegklassen mit einer MVC-Struktur organisieren. Das wird es viel einfacher machen, mehrere Jahre in die Zukunft zurückzukehren und zu wissen, was Sie gedacht haben, als Sie etwas geschrieben haben, und nur die Teile zu ersetzen, die es brauchen.

Sie sollten auch den Ratschlägen des W3C folgen und Präsentationsinformationen vollständig aus Ihrem HTML-Code entfernen. (Dazu gehören Cheats wie das Vergeben von Namen für Präsentationsklassen für Elemente wie "großer grüner Text" und "zwei Spalten breit".) Wenn Ihr HTML semantisch und CSS präsentativ ist, ist es viel einfacher, es zu pflegen und anzupassen auf neue Plattformen in der Zukunft. Es wird auch einfacher, Unterstützung für spezialisierte Browser für blinde oder behinderte Menschen hinzuzufügen.

Viertens, automatisieren Sie Ihre Tests und stellen Sie sicher, dass Sie eine nahezu vollständige Abdeckung haben. Schreiben Sie Komponententests für jede Klasse, egal ob serverseitig oder in JavaScript. Stellen Sie im Front-End sicher, dass jede Klasse in jedem unterstützten Browser gemäß ihrer Spezifikation ausgeführt wird. Automatisieren Sie diese Tests von Ihrem Build-Bot für jedes Commit. Dies ist sowohl für die Langlebigkeit als auch für die Zuverlässigkeit wichtig, da Sie Fehler frühzeitig erkennen können, selbst wenn sie von aktuellen Browsern verdeckt werden. Sowohl die JSUnit-basierten Test-Frameworks von Jasmine als auch von Google Closure sind gut.

Sie sollten auch vollständige UI-Funktionstests durchführen, in denen Selenium / WebDriver gut ist. Grundsätzlich schreiben Sie ein Programm, das Ihre Benutzeroberfläche durchläuft und es so verwendet, als würde eine Person es testen. Verdrahten Sie diese ebenfalls mit dem Build-Bot.

Wie andere bereits erwähnt haben, sind Ihre Daten König. Denken Sie über Ihr Datenspeichermodell nach und stellen Sie sicher, dass es auf Langlebigkeit ausgelegt ist. Stellen Sie sicher, dass Ihr Datenschema solide ist, und stellen Sie sicher, dass es bei jedem Commit gründlich getestet wird. Und stellen Sie sicher, dass Ihre Serverarchitektur skalierbar ist. Dies ist noch wichtiger als alles, was Sie am Frontend tun.

Abgesehen von den unangemessenen Erwartungen Ihres Kunden und der Fokussierung auf Designprobleme würde ich 40 Jahre nicht überschreiten, aber das Problem, das Sie anscheinend haben, ist genau das, wofür REST geschaffen wurde . Damit meine ich wirklich REST als einen Architekturstil, nicht das Schlagwort, das heutzutage so häufig mit dem Begriff assoziiert wird.

In gewissem Maße verstehen die Leute REST falsch, weil ich in meiner Dissertation nicht genügend Details zum Design von Medientypen angegeben habe. Das liegt daran, dass mir die Zeit ausgeht, und nicht daran, dass ich dachte, es sei weniger wichtig als die anderen Aspekte von REST. Ebenso vermute ich, dass viele Leute etwas falsch machen, weil sie nur den Wikipedia-Eintrag zu diesem Thema lesen, der nicht auf maßgeblichen Quellen basiert.

Ich denke jedoch, dass die meisten Leute einfach den Fehler machen, dass es einfach sein sollte, einfache Dinge zu entwerfen. In der Realität ist der Aufwand für das Entwerfen umgekehrt proportional zur Einfachheit des Ergebnisses. REST ist architektonisch sehr einfach.

REST ist Software-Design im Maßstab von Jahrzehnten : Jedes Detail soll die Langlebigkeit der Software und die unabhängige Weiterentwicklung fördern.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

Sie haben erwähnt, dass Sie beabsichtigen, eine RESTful-Schnittstelle zu verwenden. Dieser Kommentar an sich legt nahe, dass Sie ernsthafte Nachforschungen anstellen und versuchen sollten, zu verstehen, worum es bei REST wirklich geht. Sie verbinden es wahrscheinlich nur mit der Zuordnung von HTTP-Methoden zu CRUD-Operationen, die die meisten Leute für REST halten, aber das hat nichts damit zu tun.

Stellen Sie sich REST als eine Formalisierung der Architektur des Webs selbst vor. Auf die eine oder andere Weise gibt es viele Teile des Internets, die vor einem Jahrzehnt oder später geschrieben wurden und noch verfügbar sind und mit einem Kunden verwendet werden können, der heute erstellt wurde. Ich garantiere Ihnen, es wird eine Menge Arbeit sein, denn es ist schwierig, REST richtig zu machen, aber die langfristigen Vorteile sind es wert.

Nachdem ich die Frage und die anderen (sehr gut durchdachten) Antworten gelesen habe, habe ich gedacht, dass ich meine zwei Cent auch lassen werde. Hinweis: Ich muss überhaupt keine wirklich alte Anwendung / Software warten. Als Referenz verwende ich meine eigene Work-in-Progress-Hobby-Web-App, die einige offene Regierungsdaten erfasst, analysiert und in verschiedenen Formaten anzeigt. Die App begann als ein Projekt, in dem ich nicht alleine war und in dem die Regierung gerade angekündigt hat, dass sie diese Daten irgendwie anbieten wird. Es war also klar, dass sich mit der Zeit viele Dinge ändern werden. Und sie taten es. Was ich daraus gelernt habe:

• Teilen Sie die Dinge in Mini-Anwendungen auf. Jeder ist in der Lage, seine Aufgabe für sich zu erfüllen. Dies macht das Auswechseln eines einzelnen Teils sehr schnell, sehr sicher und sehr einfach. Und wenn Sie zurückkehren müssen, ist es nicht wirklich schwierig, herauszufinden, warum Dinge passieren und wie Sie passieren. Wenn Sie oder jemand anderes später etwas ändern muss, ist es einfacher, ein einzelnes Teil als eine ganze Reihe von Dingen zu ersetzen.
• Holen Sie sich eine solide konstante Middleware / -Layer, die für die Kommunikation zwischen den verschiedenen Teilen verwendet wird. In diesem Fall habe ich JSON verwendet, aber auch XML, INI oder ähnliche Standards wären in Ordnung. Es ist leicht zu wiederholen und kann in fast alles verwandelt werden. Alle sind bewährte Standards, die einige Zeit überleben werden. Auch wenn sich die zugrunde liegenden Daten und / oder das Speichermodell ändern. Jede der Apps kann für ihre spezifische Aufgabe einen eigenen Datenspeicher verwenden. Dadurch wird die Menge gescannter Daten für eine Aufgabe kleiner, die Handhabung und Wartung wird vereinfacht und der Austausch wird erleichtert.
• Mach dir keine Sorgen über Programmiersprachenentscheidungen. Diese werden sich im Laufe der Zeit ändern. Stellen Sie einfach sicher, dass Sie die Sprache verwenden, mit der Sie vertraut sind oder die am besten zu einer Aufgabe passt.
• Stellen Sie sicher, dass Ihr Datenspeicher horizontal skalierbar ist und dass zusätzliche Speichermodule problemlos angeschlossen werden können.
• Holen Sie sich einen gemeinsamen Punkt (in meinem Fall sind es URIs), an dem die Mini-Apps aufgerufen werden und / oder Daten austauschen.

Fazit: Am wichtigsten ist mir die Trennung der Belange und die Austauschbarkeit der für Aufgaben zugewiesenen Teile. Sie wissen einfach, dass sich in 40 Jahren (sogar in 5 oder 10 Jahren) Hardware, Schnittstellen, Speicher usw. stark verändern werden. Und spätere Entwickler müssen auf diese Änderungen reagieren und Teile Ihrer Anwendung austauschen, sei es der Datencontainer oder Teile der Benutzeroberfläche.

Planen Sie Veränderungen ein, um die Dinge so "zukunftssicher" wie möglich zu machen. Das heißt, versuchen Sie Ihr Bestes, um nicht für etwas anderes als die Fähigkeit zu optimieren, sich leicht zu ändern. Also keine Normalisierung, keine strenge Validierung und lose Kopplung in Hülle und Fülle.

• Verwenden Sie die wichtigsten Open-Source-Technologien. Bei Daten stellen Closed-Source-Systeme eine große Risikoquelle dar, da nicht geplant werden kann, welche Unternehmen untergehen oder Strategien ändern, und der gesamte Zugriff auf die Daten damit verbunden ist. Auch kleinere Open-Source-Projekte ohne eine lebendige Community verlieren mit größerer Wahrscheinlichkeit an Unterstützung.

• Verwenden Sie eine NoSQL-Datenbank ohne Schema. Die Art der unstrukturierten Daten, die verwendet werden, ist für einen Dokumentenspeicher wie MongoDB fast aus dem Lehrbuch entfernt. Traditionelle relationale Datenbanken und ihre Normalisierung sind gut, wenn Sie wissen, wie Ihre Daten strukturiert werden, aber das ist wirklich eine Fiktion, besonders hier. Die Kosten für die Änderung des Schemas in einem RDBS werden mit zunehmender Systemerweiterung immer höher. Wisse, dass sich die Struktur, die jetzt gewählt wird, ändern wird.

• Entkoppeln Sie das System stark mit allgemein anerkannten Standards. Die Aufteilung aller Datenzugriffe und Mutationen in Webdienste ist ein Schritt in diese Richtung. Wenn Sie dies mit Nachrichtenwarteschlangen zum Senden von Änderungen kombinieren, können einzelne Teile des Systems im Laufe der Zeit Sprachen oder Technologien ändern.

OK, also werde ich hier einige Dinge sagen, die wahrscheinlich ziemlich unbeliebt sein werden, aber bleib hier bei mir.

Da dies Ihr erstes Projekt ist, in dem die Daten und / oder die Anwendung mehr als 20 Jahre dauern sollen, und Sie derjenige sind, der das Projekt leitet, müssen Sie einen Schritt zurücktreten und darüber nachdenken, wie die Erfolgsaussichten dieses Projekts stehen . Weil sie im Grunde gegen Null sind.

Sie müssen viel Zeit darauf verwenden, sich auf das Datenbankdesign zu konzentrieren und es richtig zu machen. Damit dieses Projekt erfolgreich ist, müssen Sie einen Datenarchitekten in das Projekt einbeziehen, und zwar eher früher als später. Ohne jemanden, der Erfahrung im Datenbankdesign hat und sich darauf freut, wie die Daten in Zukunft verwendet werden können, ist die Wahrscheinlichkeit gering, dass die Daten nach 5 Jahren und noch viel weniger als 40 Jahren noch nützlich sind.

Zu erwarten, dass zwei Leute (von denen einer den Titel jr. Dev trägt) etwas von Grund auf neu bauen, was voraussichtlich 40 Jahre dauern wird, wird wahrscheinlich keinen Erfolg haben. Es sollte ein Team von Leuten geben, die viel Erfahrung in der Arbeit mit großen Projekten wie diesem haben und am Datendesign, dem API-Design und dem Anwendungsdesign arbeiten. So etwas ist kein 2-Personen-Projekt.

Der Wunsch, das Projekt an etwas wie Drupal zu binden, zeigt, warum das Projekt Menschen benötigt, die es gewohnt sind, an solchen Projekten zu arbeiten. Sie möchten die Anwendung nicht an irgendetwas binden, das innerhalb weniger Jahre aus der Mode kommen könnte. In diesem Fall könnte es sehr schnell schwierig werden, jemanden zu finden, der in 5-10 Jahren an dem System arbeitet.

Ich würde diesen Rat an die Geschäftsleitung weitergeben und ihnen erklären, dass Sie mehr Senioren für das Projekt gewinnen müssen. Andernfalls ist das Projekt zum Scheitern verurteilt, und Sie werden wahrscheinlich derjenige sein, der die Schuld dafür trägt.

Die Anwendung muss 40 Jahre ohne Evolution nicht überleben. Aber weil es von Grund auf neu gebaut werden würde oder sollte, könnte es immer noch "funktionieren".

Was am wichtigsten ist, ist die „Datenarchitektur“, die Stabilität und Governance bietet und erweiterbar ist.

Wir haben Datenarchitektur und -taxonomie entworfen, die das Ende der Menschheit fast überleben könnten, aber trotzdem erweiterbar sind. Sie haben eine echte DATA TAXONOMY / DATA ARCHITECTURE-Person gefunden, die dies für Sie erledigt.

Der Schlüssel hier ist, sich auf die Datenbank zu konzentrieren (wie bereits erwähnt). Dies muss kohärent sein und die Funktionsweise vollständig beschreiben. Es muss mit der Operation mitwachsen, wenn es sich ändert. Wenn es nicht einfach ist, sich zu ändern, wird es veraltet sein und das ist der Kuss des Todes. Der Rest ist relativ unwichtig.

Ich stimme den oben genannten Personen nicht zu, die meinen, Normalisierung sei nicht wichtig, obwohl es immer Fälle gibt, in denen die aktuellen Systeme den Anforderungen nicht gerecht werden. In diesen Fällen denormalisieren Sie, stellen Sie jedoch sicher, dass die Datenbank die zusätzlichen Schreib- / Änderungsvorgänge als Teil einer atomaren Transaktion verarbeitet. Auf diese Weise können Sie das Problem effektiv ignorieren, bis Sie es beheben können.

Das Unternehmen, für das ich vor meiner Pensionierung gearbeitet habe, betreibt ein System, das von Grund auf neu entwickelt wurde und seit 25 Jahren nahezu kontinuierlich wächst und nahezu alle Aspekte eines mittleren Einzelhändlers abdeckt. Aspekte dieses Systems, die ich für wichtig halte, sind:

• Integration ist lebenswichtig.
• Die Datenbank muss sowohl für die IT als auch für andere Mitarbeiter korrekt und verständlich sein. Daher ist eine fast paranoide Betonung der Benennung erforderlich. Wir haben Tabellen mit definierten Mnemonics, die dann zu Tabellen- und Feldnamen zusammengefasst werden. Alle „Codes“ wurden ebenfalls als Konstanten benannt und in einer EAV-Tabellenstruktur gespeichert.
• Wir haben Geschäftslogik in Datenbank-Trigger eingekapselt. Dies ist zunächst schmerzhaft und erfordert zusätzlichen Aufwand, um Fehlermeldungen an Clients zu senden und Trigger flexibel ändern zu können, ohne die gesamte Tabelle auf einigen Systemen zu sperren. Dies spart jedoch schnell viel Zeit und zwingt die Datenbank dazu, viel korrekter zu sein als sonst.
• Angenommen, Sie behalten mindestens Referenztabellen (im Idealfall alle bis auf die schnellsten und am wenigsten wichtigen Transaktionen) für die Lebensdauer des Systems, auch wenn diese "gelöscht" wurden, damit Ihre Referenzen korrekt sind.
• Stellen Sie deshalb sicher, dass alle eindeutigen Bezeichner und Transaktionsnummern langfristig dimensioniert sind. (Ich habe ursprünglich im Scherz vorgeschlagen, dass sie bis zu meiner Pensionierung Bestand haben sollten).

Ich würde vorschlagen, Event-Sourcing und die Trennung von Befehls- und Abfrageverantwortung zu verwenden . Dies liegt hauptsächlich daran, dass Sie sich nur bei den Ereignissen sicher sein können, die bereits aufgetreten sind. Neue Arten von Ereignissen könnten kommen. Selbst wenn Sie sich Gedanken über ein Modell machen, ist es sicher, dass dies veraltet sein wird. Das Migrieren aller Daten mit jeder Version ist möglicherweise nicht möglich. Am besten ist es also, ein Modell zu haben, das Ihren aktuellen Anforderungen entspricht und das jedes Mal, wenn Sie es benötigen, aus bereits aufgezeichneten Ereignissen berechnet wird, und dann Ereignisse zu verteilen, die aus dem aktuellen Status dieses Modells berechnet werden.

Denken Sie auch an Tests. Wenn die Anwendung in zehn Jahren verwendet wird, müssen Tester sicherstellen, dass sie immer noch das tut, was sie tun soll. Machen Sie das Testen Ihrer Anwendung durch Integration so einfach wie möglich.