IsyFact Architekturregeln

Vererbungshierarchien zur Abbildung in relationalen Datenbanken sollten nur verwendet werden, wenn das fachliche Datenmodell dadurch optimal wiedergegeben wird. Sie sollten nur eine Oberklasse mit einigen Subklassen und höchstens zwei Vererbungsebenen umfassen.

Metadaten sind, egal über welches Protokoll sie übertragen werden, einheitlich benannt. Gibt es eine durch einen Standard vorgegebene Benennung, ist diese zu verwenden.

Synchrone Service-Aufrufe finden über das Protokoll HTTP statt und werden sowohl zur internen als auch externen Servicekommunikation genutzt. HTTP-Anfragen bzw. HTTP-Antworten (s. Abbildung 1) erlauben es an drei Stellen, anwendungsspezifische Daten zu übertragen: in der URL, in den Headern sowie im Body.

Header enthalten Metadaten. Der Body enthält Nutzdaten. Bei Anfragen mittels GET und DELETE, die keinen Body erwarten, enthalten URL-Parameter Nutzdaten.

Persistente Entitäten dürfen nicht über den Anwendungskern hinaus herausgegeben werden. Sie haben im Anwendungskern zu verbleiben.

Beim Loggen der Nachrichten sind grundsätzlich die Vorgaben der Datenschutzgrundverordnung (DSGVO) einzuhalten. Eine besondere Rolle spielen dabei personenbezogene Daten und insbesondere Daten gemäß Artikel 9 DSGVO. Ebenso dürfen grundsätzlich keine sicherheitsrelevanten Daten (z.B. Passwörter) geloggt werden.

Logback wird durch eine Anwendung niemals direkt, sondern ausschließlich über die Bibliothek isy-logging aufgerufen. Dadurch wird die einheitliche Nutzung von logback sichergestellt. Ausnahmen sind hierbei externe Bibliotheken (siehe Logging externer Bibliotheken).

Wenn das fachliche Datenmodell variable Sichtbarkeitsregeln in größerem Umfang benötigt, sollten diese mit Hibernate Filtern umgesetzt werden.

Die Single Table per Class Hierarchy Strategie sollte die Default-Strategie sein, weil sie performante Abfragen erlaubt.

Wenn Not-Nullable-Constraints zwingend erforderlich sind und polymorphe Queries benötigt werden, ist die Joined Subclass Strategie eine gute Wahl. Ein weiteres Argument für diese Strategie sind Subklassen mit vielen Attributen.

Die Table per Concrete Class Strategie sollte, wenn überhaupt, nur gewählt werden, wenn die anderen Strategien nicht passen und auf die Oberklasse keine oder nur wenig polymorphe Zugriffe zu erwarten sind.

Diese Art der Vererbung von einer Java-Oberklasse auf Entitäten-Subklassen kann eingesetzt werden, wenn nur auf die Subklassen zugegriffen werden muss.

Ein auf der IsyFact basierendes IT-System muss seine REST-Services mindestens anhand Stufe zwei des Richardson Maturity Models umsetzen.

Es dürfen nur nicht datenschutzrelevante Informationen in Query Parametern verwendet werden, um das Loggen von datenschutzrelevanten Daten zu verhindern.

POST wird auch für fachliche Operationen genutzt, die keiner der anderen HTTP-Methoden zugeordnet werden können (z. B. Verifikation eines Antrags).

PATCH ist nur zu verwenden, wenn PUT aus triftigen Gründen nicht funktioniert.

Alle REST-Services innerhalb einer Systemlandschaft nutzen eine einheitliche, textbasierte Repräsentationsform. Binäre Daten werden über direkte Anfragen binär ohne Transformation zurückgeliefert.

REST-Schnittstellen verwenden ausschließlich Transferobjekte (Data Transfer Objects, DTOs).

Der Anwendungscode für Tasks muss mindestens die folgenden Informationen ins Log schreiben: