Bei der Full-Stack Entwicklung haben wir es mit verschiedenen Arten von „Modellen“ zu tun.
Diese werden hier kurz aufgelistet:
Frontend
Input-Requests
Im Frontend gibt es Use-Cases. Jeder Use-Case hat Input-Modelle, die ich als „Requests“ bezeichne.
z.B.
export class AddAreaLocationRequest {
AreaId: string;
MasterdataSiteId: string;
}
Output-Responses
Genauso kann ein Use-Case auch wieder einen Output haben. Die „Responses“:
export class DataGroupedByEnterprisesGetItemsResponse {
Enterprises: EnterpriseEntity[];
AllAreas: AreaEntity[];
EnterpriseComponentDefinition: ComponentDefinitionEntity;
}ViewModels
Die Daten aus den Responses können in View-Models gesammelt werden, die schließlich die Daten einer Komponenten liefern.
export class DataGroupedByOrdersViewModel
implements DataGroupedViewModel {
ExpandedContent: {[key: string]: DataGroupedByOrdersExpandOrderResponse};
GetItems: DataGroupedByOrdersGetItemsResponse;
ShowItem: DataGroupedByOrdersShowItemDetailsResponse;
}ApiViewModels
Die Use-Cases schreiben Ihre Daten in Repositories, die schließlich mit dem Backend kommunizieren. Hierfür müssen natürlich dieselben Modelle verwendet werden, die die API erwartet.
Es sind also ApiViewModels, die auch im Backend verwendet werden.
Backend
ApiViewModels
ApiViewModels werden von der API entgegengenommen. Sie dienen auch zur automatischen Dokumentation der APIs, denn der OpenAPI standard wird diese Modelle als Referenz für seine Docs verwenden.
Input-Requests
Analog zum Frontend gibt es jetzt auch wieder Input-Requests, die die Use-Cases auf API-Seite als Input erhalten. Die Versuchung ist da hier dieselben Klassen wie die ApiViewModels zu verwenden, weil sie oft sehr ähnlich oder sogar gleich sind. Diesen Fehler sollte man nicht machen und wirklich ein neues Modell schreiben.
Output-Respones
Auch die Use-Cases im Backend haben natürlich einen Response.
DatabaseModels
Am Ende liegen die Daten in der Datenbank.
Hier haben sie auch ein bestimmtes Format, in dem sie persistiert werden. Auch hierfür gibt es Modelle.
Configurations
Configurations sind Modelle, die verwendet werden, um den Zustand von Umgebungsvariablen oder Konfigurationsdateien darzustellen, die für den Betrieb der App benötigt werden. Sie können sich z.B. zwischen Test, Dev und Prod Systemen unterscheiden.
Allgemein
Value-Objects
Objekte ohne eigene Identität, die einfach nur von Services, Entitäten verwendet werden können.
Entities
Klassen die Hauptakteure einer Software darstellen. Beinhalten den zentralen Teil der Business-Logik.
Beim Umgang mit Entities ist wichtig, dass sie richtig in Database-Models persistiert und „wiederbelebt“ werden können.
Service-Adapters
Sind Service-Klassen, die eine bestimmte Infrastruktur zur Verfügung stellen, die die App benötigt. Diese sollten sich hinter einem Interface verbergen, damit sie ausgetauscht werden können. Z.B. IGraph, IServiceBus
Use-Cases
Bilden die konkreten Anwendungsfälle der App ab und stehen in enger Verbindung mit den Entities. Use-Cases sollten so schlank wie möglich sein. Der größte Teil der Business Logik sollte in den Entities liegen.
Repositores
Bieten die Möglichkeit mit der Außenwelt zu kommunizieren. Sollten als Adapter abgebildet werden, damit sie austauschbar und Testbar sind.
