Entwerfen eines Internet-Kreditkaufsystems

Während eines der technischen Interviews, mit denen ich konfrontiert wurde, wurde ich gebeten, ein E-Commerce-System zu entwerfen, das es Benutzern ermöglicht, Internetguthaben von Drittanbietern zu erwerben.

Ich habe selbstbewusst eine unkomplizierte Lösung vorgeschlagen: Verfügbare Pakete anzeigen, Benutzer eines auswählen lassen, Zahlungen über ein externes Gateway abwickeln und mit dem Anbieter interagieren, um die Gutschriften zu liefern. Als ich jedoch nach Fehlerszenarien gefragt wurde – etwa, dass der Anbieter nicht mehr vorrätig ist, nachdem ein Benutzer die Zahlung abgeschlossen hat –, wurde mir klar, dass meinem Design die Widerstandsfähigkeit fehlte, um solche Probleme effektiv zu bewältigen.

Vor ein paar Wochen habe ich Untersuchungen zu Flash-Sale-Systemen und Bestandsreservierungsmustern durchgeführt, wobei ich mich insbesondere auf Bestandsreservierungsstrategien konzentriert habe. Flash-Verkäufe sind oft mit einer hohen Nachfrage und begrenzten Lagerbeständen konfrontiert und erfordern ausgefeilte Mechanismen, um die Systemstabilität aufrechtzuerhalten und die Kundenerwartungen zu erfüllen. Ein Konzept, das ich entdeckt habe, waren vorübergehende Lagerreservierungen, die dazu beitragen, Überverkäufe in Spitzenzeiten zu verhindern.

Diese Recherche erinnerte mich an meine Interviewerfahrung. Mir wurde klar, dass die Anwendung dieser Bestandsreservierungsstrategien die Mängel meines ursprünglichen Entwurfs hätte beheben können. Durch die Einbeziehung vorübergehender Lagerbestände während des Bezahlvorgangs könnte das System effektiv mit Situationen umgehen, in denen der Lagerbestand des Anbieters aufgebraucht ist.

In dieser Forschungsdokumentation möchte ich die Erkenntnisse aus meiner Forschung weitergeben und einen verfeinerten Ansatz für die Gestaltung eines Internet-Kreditkaufsystems vorschlagen. Durch die Integration von Bestandsreservierungsstrategien können wir eine Plattform aufbauen, die sowohl robust als auch benutzerfreundlich ist, in der Lage ist, verschiedene Fehlerszenarien zu bewältigen und gleichzeitig ein nahtloses Erlebnis zu bieten.

1. Wichtige Designüberlegungen

Beim Entwerfen eines Internet-Kreditkaufsystems müssen einige Schlüsselfaktoren berücksichtigt werden, um ein nahtloses, sicheres und angenehmes Benutzererlebnis zu gewährleisten. Lassen Sie uns sie aufschlüsseln:

1.1 Quotenverwaltung

• Kontingentüberprüfung in Echtzeit: Das System sollte sofort prüfen, ob die Internet-Guthabenpakete auf Lager sind, damit Benutzer nicht versehentlich nicht verfügbare Optionen auswählen.
• Vorübergehende Kontingentreservierung: Fügen Sie einen Mechanismus hinzu, um ein ausgewähltes Paket für einen kurzen Zeitraum aufzubewahren, sodass Benutzer genügend Zeit haben, ihren Kauf abzuschließen, ohne das Risiko einzugehen, den Artikel zu verlieren.
• Umgang mit Kontingentkonflikten: Entwickeln Sie Strategien zur Bewältigung von Situationen, in denen mehrere Benutzer gleichzeitig versuchen, dasselbe Paket zu kaufen, und sorgen Sie so für eine faire Zuteilung.
• Cache-Verwaltung für Paketinformationen: Halten Sie die Cache-Daten korrekt und aktuell, damit Benutzer immer die richtigen Details und Verfügbarkeit sehen.

1.2 Zahlungsabwicklung

• Sichere Zahlungsabwicklung: Implementieren Sie strenge Sicherheitsmaßnahmen, um die Zahlungsdaten der Benutzer bei Transaktionen zu schützen.
• Treuhandsystem zum Zahlungsschutz: Nutzen Sie einen Treuhandservice, um Gelder bis zur Lieferung der Gutschriften aufzubewahren und so sowohl Käufer als auch Anbieter zu schützen.
• Zahlungsgateway-Integration: Stellen Sie sicher, dass das System reibungslos mit zuverlässigen Zahlungsgateways verbunden ist, um problemlose Transaktionen zu gewährleisten.
• Rückerstattungsmechanismen: Erstellen Sie klare und benutzerfreundliche Prozesse für die Gewährung von Rückerstattungen im Falle fehlgeschlagener Zahlungen oder Stornierungen.

1.3 Anbieterintegration

• Systemverfügbarkeit: Arbeiten Sie mit Anbietern zusammen, die über zuverlässige Systeme verfügen, um sicherzustellen, dass Einkäufe ohne Unterbrechungen abgewickelt werden.
• API-Zuverlässigkeit: Arbeiten Sie mit Anbietern zusammen, die stabile, gut dokumentierte APIs für eine nahtlose Integration anbieten.
• Überprüfung der Serviceaktivierung: Fügen Sie Überprüfungen ein, um zu bestätigen, dass gekaufte Credits ordnungsgemäß und umgehend aktiviert werden.
• Fehlerbehandlung und Wiederholungen: Implementieren Sie Protokolle, um Fehler schnell zu erkennen und zu beheben, mit Wiederholungsmechanismen für alle fehlgeschlagenen Prozesse.

1.4 Transaktionssicherheit

• Geldflusskontrolle: Stellen Sie sicher, dass Gelder erst freigegeben werden, nachdem Transaktionen erfolgreich abgeschlossen wurden.
• Transaktionskonsistenz: Führen Sie genaue und konsistente Aufzeichnungen aller Transaktionen, um Fehler zu vermeiden.
• Rollback-Mechanismen: Planen Sie, Transaktionen rückgängig zu machen, wenn etwas schief geht, um sowohl Benutzer als auch das System zu schützen.
• Audit Trail: Führen Sie detaillierte Protokolle, um Probleme effektiv zu überwachen und zu beheben.

1.5 Benutzererfahrung

• Fehlermeldungen löschen: Stellen Sie Benutzern verständliche und informative Fehlermeldungen zur Verfügung, die sie bei aufgetretenen Problemen unterstützen.
• Transaktionsstatus-Sichtbarkeit: Ermöglichen Sie Benutzern die einfache Verfolgung des Status ihrer Einkäufe in Echtzeit und erhöhen Sie so die Transparenz.
• Schnelles Laden von Paketen: Optimieren Sie das System, um verfügbare Pakete schnell zu laden und so die Wartezeiten für Benutzer zu reduzieren.
• Echtzeit-Updates: Halten Sie Benutzer umgehend über Änderungen oder Aktualisierungen ihrer Transaktionen oder verfügbaren Pakete auf dem Laufenden.

Durch die Berücksichtigung dieser Überlegungen können wir ein Online-Kreditkaufsystem entwickeln, das effizient, sicher und benutzerfreundlich ist und zu höherer Benutzerzufriedenheit und höherem Vertrauen führt.

2. Systemdesign und -fluss

Aufbauend auf den oben dargelegten grundlegenden Überlegungen besteht der nächste Schritt darin, diese Prinzipien in ein robustes und effektives Systemdesign zu übersetzen. Indem wir die Interaktionen zwischen verschiedenen Komponenten sorgfältig abbilden, können wir sicherstellen, dass das System nicht nur die funktionalen Anforderungen erfüllt, sondern auch ein nahtloses Benutzererlebnis bietet und gleichzeitig Zuverlässigkeit und Skalierbarkeit beibehält.

In diesem Abschnitt befassen wir uns mit der Architektur und dem Ablauf des Systems und zeigen, wie die Kernfunktionen – wie Kontingentverwaltung, Zahlungsabwicklung und Serviceaktivierung – zusammenhängend implementiert werden. Ziel ist es, hervorzuheben, wie jede Designauswahl dazu beiträgt, potenzielle Herausforderungen zu bewältigen und eine zuverlässige E-Commerce-Kreditkaufplattform bereitzustellen.

Beginnen wir mit einem Überblick über den Systemfluss, visualisiert durch ein Flussdiagramm, um zu veranschaulichen, wie Benutzer von Anfang bis Ende mit dem System interagieren.

2.1 Flussdiagramm

Der Systemablauf ist der Übersichtlichkeit halber in sechs Phasen unterteilt:

Paketauswahlphase

• Zuerst besucht der Benutzer die Paketauswahlseite, wo die App Paketdaten aus einem Cache abruft. Zu diesen Daten gehören verfügbare Pakete und ihre zwischengespeicherten Kontingentinformationen, die dann dem Benutzer angezeigt werden.
• Der Benutzer wählt ein Paket aus und klickt auf „Kaufen“.
• Wenn das Kontingent für dieses Paket nicht verfügbar ist, zeigt die App die Meldung „Nicht verfügbar“ an und führt den Benutzer zurück zur Auswahlseite. Andernfalls reserviert das System vorübergehend das Kontingent für den Benutzer.

Kaufanbahnung

• Als nächstes versucht das System, das Kontingent für das ausgewählte Paket zu reservieren.
• Wenn die Reservierung fehlschlägt, wird dem Benutzer eine Fehlermeldung angezeigt und er wird zurück zur Auswahlseite weitergeleitet.
• Wenn die Reservierung erfolgreich ist, gelangt der Benutzer zur Zahlungsseite.

Zahlungsphase

• In diesem Stadium startet der Benutzer den Zahlungsvorgang und wird zu einem Zahlungsgateway eines Drittanbieters weitergeleitet.
• Die App wartet auf eine Antwort (Rückruf) vom Zahlungsgateway, um den Zahlungsstatus zu bestätigen.

Zahlungsabwicklung

• Die App prüft den Rückruf des Zahlungsgateways, um die Zahlung zu validieren:
  • Bei ungültigen Rückrufen protokolliert das System das Problem und stoppt weitere Schritte.
  • Für gültige Rückrufe:
    • Wenn die Zahlung fehlschlägt: Das System gibt das reservierte Kontingent frei und informiert den Benutzer über das Problem.
    • Wenn die Zahlung erfolgreich ist: Das System überprüft die Zahlung, speichert den Betrag treuhänderisch und erstellt eine neue Bestellung.

Dienstaktivierung

• Sobald die Zahlung erfolgreich ist, fordert das System den Anbieter auf, den Dienst zu aktivieren.
  • Wenn die Aktivierung fehlschlägt: Das Treuhandgeld wird dem Kunden zurückerstattet und er wird über den Fehler benachrichtigt.
  • Wenn die Aktivierung erfolgreich ist: Das System überprüft die Aktivierung.
    • Wenn die Verifizierung fehlschlägt, erhält der Kunde eine Rückerstattung.
    • Wenn die Überprüfung erfolgreich ist, werden die Treuhandgelder an den Anbieter freigegeben und der Kunde erhält eine Benachrichtigung.

Hintergrundprozesse

• Periodische Cache-Updates: Der Paketdaten-Cache wird regelmäßig aktualisiert.
• Kontingentaktualisierungen in Echtzeit: Kontingentänderungen werden über WebSocket-Verbindungen kommuniziert.

Dieser Ablauf gewährleistet ein reibungsloses, zuverlässiges Erlebnis für Benutzer und verwaltet gleichzeitig Ressourcen und potenzielle Fehler effektiv.

2.2 Sequenzdiagramm

Das folgende Sequenzdiagramm hilft, die Interaktion zwischen verschiedenen Rollen und Komponenten zu veranschaulichen.

Der Systemablauf ist der Übersichtlichkeit halber in sechs Phasen unterteilt:

Paketauswahlphase

• Der Kunde besucht zunächst die Paketauswahlseite.
• Das Frontend ruft Paketdaten aus dem Cache ab und zeigt dem Kunden alle verfügbaren Pakete zusammen mit ihren zwischengespeicherten Kontingentinformationen an.

Kaufanbahnung

• Sobald der Kunde ein Paket auswählt und auf „Kaufen“ klickt, sendet das Frontend eine Kaufanfrage an das Backend.
• Das Backend prüft in Echtzeit beim Anbieter, ob das Kontingent des ausgewählten Pakets noch verfügbar ist.
• Wenn das Kontingent verfügbar ist, reserviert das Backend es vorübergehend für 15 Minuten beim Anbieter.
• Das Backend sendet dann eine Reservierungsbestätigung an das Frontend und der Kunde wird zur Zahlungsseite weitergeleitet.

Zahlungsphase

• Der Kunde geht zur Zahlungsseite und gibt seine Zahlungsdaten ein.
• Das Frontend sendet diese Informationen an das Backend, das eine Zahlungssitzung mit dem Zahlungsgateway initialisiert.
• Sobald die Zahlungssitzung bereit ist, teilt das Backend die Sitzungsdetails mit dem Frontend.
• Das Frontend leitet den Kunden zum Zahlungsgateway weiter, um die Zahlung abzuschließen.

Zahlungsabwicklung

• Am Zahlungsgateway gibt der Kunde seine Zahlungsinformationen ein und schließt den Zahlungsvorgang ab.
• Das Zahlungsgateway benachrichtigt das Backend über einen Rückruf über den Zahlungsstatus:
  • Wenn die Zahlung erfolgreich ist:
    • Das Backend überprüft den Zahlungsstatus mit dem Zahlungsgateway.
    • Die Zahlung wird treuhänderisch verwahrt und das Backend bestätigt die Treuhandverwahrung.
  • Wenn die Zahlung fehlschlägt:
    • Das Backend gibt das reservierte Kontingent beim Anbieter frei und aktualisiert den Zahlungsstatus, um den Fehler widerzuspiegeln.
  • Wenn innerhalb der erwarteten Zeit kein Rückruf eingeht:
    • Das Backend fragt regelmäßig das Zahlungsgateway ab, um den Zahlungsstatus zu überprüfen. Wenn die Zahlung fehlschlägt oder eine Zeitüberschreitung auftritt, gibt das Backend das reservierte Kontingent frei.

Dienstaktivierung

• Wenn die Zahlung erfolgreich ist, fordert das Backend den Anbieter auf, den Dienst zu aktivieren.
• Der Anbieter antwortet mit dem Aktivierungsstatus und das Backend überprüft die Aktivierung:
  • Wenn die Aktivierung erfolgreich ist:
    • Das Backend gibt die Zahlung vom Treuhandkonto an den Anbieter frei.
    • Eine Erfolgsbenachrichtigung wird an den Kunden gesendet, um ihn darüber zu informieren, dass der Dienst bereit ist.
  • Wenn die Aktivierung fehlschlägt:
    • Das Backend erstattet dem Kunden die hinterlegten Gelder.
    • Eine Fehlermeldung wird gesendet, um den Kunden über das Problem zu informieren.

Hintergrundprozesse

• Der Anbieter sendet Echtzeit-Updates zu Paketkontingenten über WebSocket-Verbindungen an das Backend.
• Diese Aktualisierungen stellen sicher, dass der Cache immer auf dem neuesten Stand ist, sodass Kunden beim Durchsuchen die genaueste Paketverfügbarkeit sehen.

3. Technische Umsetzung

Nachdem wir nun den Ablauf und die Interaktionen des Systems skizziert haben, ist es an der Zeit, sich damit zu befassen, wie alles im Code zusammenwirkt. In diesem Abschnitt wird die Implementierung Schritt für Schritt aufgeschlüsselt und gezeigt, wie das Design in funktionierende Teile übersetzt wird, die alles von der Verwaltung von Bestellungen bis zur Interaktion mit Anbietern und Zahlungssystemen abwickeln.

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

Das machen diese Kurse:

• Paket: Hier definieren wir die Internet-Credit-Pakete, die Benutzer erwerben können. Es verfolgt Details wie Paket-ID, Name, Preis, Anbieterkosten, Beschreibung und ob das Paket aktiv ist oder nicht.

• Bestellung: Betrachten Sie dies als eine Aufzeichnung der Benutzerkäufe. Es enthält Informationen wie die Bestell-ID, die Kunden-ID, die ausgewählte Paket-ID und zugehörige Details wie die Reservierungs-ID, die Zahlungs-ID, die Treuhand-ID, den Bestellstatus, den Zahlungsbetrag, die Anbieterkosten und Zeitstempel.

• QuotaReservation: Hiermit werden temporäre Reservierungen für Paketkontingente verwaltet. Es protokolliert die Reservierungs-ID, das Paket, an das es gebunden ist, wann es abläuft und seinen aktuellen Status (z. B. aktiv oder abgelaufen).

• OrderStatus Enum: Diese Enumeration bildet alle möglichen Phasen ab, die eine Bestellung durchlaufen kann, von ERSTELLT und RESERVIERT bis ZAHLUNG_PENDING, ABGESCHLOSSEN oder sogar RÜCKERSTATTET.

• ReservationStatus Enum: In ähnlicher Weise verfolgt diese Enumeration den Status einer Kontingentreservierung, unabhängig davon, ob diese AKTIV, ABGELAUFEN, VERWENDET oder ABGESAGT ist.

Zusammen bilden diese Klassen und Aufzählungen das Rückgrat für die Verwaltung von Paketen, Bestellungen und Kontingentreservierungen im System. Es handelt sich um einen einfachen, aber strukturierten Ansatz für den effektiven Umgang mit E-Commerce-Funktionen.

// Request/Response DTOs
@Getter @Setter
public class OrderRequest {
    private String customerId;
    private String packageId;
    private BigDecimal amount;
}

@Getter @Setter
public class PaymentCallback {
    private String orderId;
    private String paymentId;
    private String status;
    private BigDecimal amount;
    private LocalDateTime timestamp;
}

@Getter @Setter
public class QuotaResponse {
    private String packageId;
    private boolean available;
    private Integer remainingQuota;
    private LocalDateTime timestamp;
}

@Getter @Setter
public class ReservationResponse {
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

@Getter @Setter
public class ActivationResponse {
    private String orderId;
    private boolean success;
    private String activationId;
    private String errorCode;
    private String errorMessage;
}

@Getter @Setter
public class VerificationResponse {
    private String orderId;
    private String activationId;
    private boolean success;
    private String status;
    private LocalDateTime activatedAt;
}

@Getter @Setter
public class PaymentRequest {
    private String orderId;
    private BigDecimal amount;
    private String currency;
    private String customerId;
    private String returnUrl;
    private String callbackUrl;
}

@Getter @Setter
public class PaymentSession {
    private String sessionId;
    private String paymentUrl;
    private LocalDateTime expiresAt;
    private String status;
}

@Getter @Setter
public class EscrowResponse {
    private String id;
    private String paymentId;
    private BigDecimal amount;
    private String status;
    private LocalDateTime createdAt;
}

Lassen Sie es uns aufschlüsseln:

• OrderRequest: Hier geht es um die Daten, die zum Erstellen einer neuen Bestellung benötigt werden. Dazu gehören die Kundennummer, das Paket, das er kaufen möchte, und der Gesamtbetrag, den er zahlen wird.

• PaymentCallback: Betrachten Sie dies als eine Benachrichtigung vom Zahlungsgateway. Nach einem Zahlungsversuch werden Details wie die Bestell-ID, die Zahlungs-ID, der Status (Erfolg oder Misserfolg), der gezahlte Betrag und der Zeitpunkt der Zahlung angezeigt.

• QuotaResponse: Hier geht es um die Überprüfung der Verfügbarkeit. Es sagt uns, ob ein Paket verfügbar ist, wie viel Kontingent noch übrig ist und wann die Informationen zuletzt aktualisiert wurden.

• ReservationResponse: Sobald ein Paket reserviert ist, erhalten Sie hier alle Details: die Reservierungs-ID, das zugehörige Paket, wann die Reservierung abläuft und ihren aktuellen Status (z. B. aktiv oder abgelaufen). .

• ActivationResponse: Hier erfahren wir, wie die Dienstaktivierung verlaufen ist. Wenn es erfolgreich war oder fehlgeschlagen ist, erhalten wir eine Aktivierungs-ID und Fehlerdetails, falls etwas schief gelaufen ist.

• VerificationResponse: Nach der Aktivierung überprüfen wir, ob alles reibungslos verlaufen ist. Dazu gehören die Bestell-ID, die Aktivierungs-ID, der Erfolgsstatus und der Zeitpunkt der Aktivierung.

• PaymentRequest: Bevor der Zahlungsprozess gestartet wird, sammelt dieses DTO die notwendigen Details wie die Bestell-ID, den zu zahlenden Betrag, die Währung, die Kunden-ID und Rückruf-URLs.

• PaymentSession: Dies wird erstellt, wenn der Zahlungsprozess beginnt. Dazu gehören die Sitzungs-ID, die Zahlungs-URL (wo der Benutzer zum Bezahlen geht), das Ablaufdatum und den Sitzungsstatus.

• EscrowResponse: Wenn die Gelder treuhänderisch verwahrt werden, verrät uns dies alles darüber – wie die Treuhand-ID, die Zahlungs-ID, den gehaltenen Betrag, den Status und den Zeitpunkt der Erstellung.

Alle diese Klassen definieren die Bausteine ​​für die Kommunikation zwischen verschiedenen Teilen des Systems – unabhängig davon, ob es sich um ausgehende Anfragen oder um zurückkommende Antworten handelt. Sie stellen sicher, dass alle (und alles) auf dem gleichen Stand sind.

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

Cache-Dienst

1. Zweck:

Dieser Dienst kümmert sich um einen lokalen Cache, der Paketdaten speichert. Ziel ist es, das System schneller zu machen und unnötige Aufrufe der API des Anbieters zu reduzieren.

2. Hauptmerkmale:

• updateCache(): Diese Methode aktualisiert den lokalen Cache alle 5 Minuten, indem sie alle Paketdaten vom Anbieter abruft. Es stellt sicher, dass der Cache auf dem neuesten Stand bleibt.
• getPackage(): Diese Methode ruft Paketinformationen anhand ihrer ID aus dem Cache ab.
• updatePackageQuota(): Wenn sich Kontingentdetails ändern, aktualisiert diese Methode den Cache mit den neuen Informationen für ein bestimmtes Paket.

Anbieterintegration

1. Zweck:

Dieser Dienst übernimmt die Kommunikation mit der API des Anbieters. Es verwaltet Aufgaben wie die Überprüfung von Kontingenten, die Reservierung von Paketen, die Aktivierung von Diensten und die Überprüfung dieser Aktivierungen.

2. Hauptmerkmale:

• checkQuota(): Diese Methode prüft, ob für ein Paket genügend Kontingent verfügbar ist, indem sie die API des Anbieters aufruft.
• ReserveQuota(): Es reserviert das Kontingent eines Pakets für einen Kunden, indem es eine Anfrage an den Anbieter sendet.
• activateService(): Wenn es Zeit ist, einen Dienst für eine Bestellung zu aktivieren, verarbeitet diese Methode die Anfrage an den Anbieter.
• verifyActivation(): Nach der Aktivierung bestätigt diese Methode, ob alles erfolgreich war.
• getAllPackages(): Diese Methode ruft alle verfügbaren Pakete vom Anbieter ab, was nützlich ist, um den Cache zu aktualisieren oder den Benutzern Paketoptionen anzuzeigen.

3. Wiederholungsmechanismus:

Der Dienst verwendet RetryTemplate, um Anfragen an die API des Anbieters automatisch erneut zu versuchen, wenn vorübergehende Probleme auftreten. Dies stellt sicher, dass das System auch bei kleineren Störungen zuverlässig und belastbar bleibt.

Durch die Kombination dieser Funktionen stellt dieser Code sicher, dass das System Paketdaten effizient verwaltet und gleichzeitig eine reibungslose und zuverlässige Kommunikation mit der API des Anbieters aufrechterhält.

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

Zahlungs-Gateway-Integration

Dieser Kurs spielt eine Schlüsselrolle bei der Verwaltung der Interaktion des Systems mit dem Zahlungsgateway, um Finanztransaktionen reibungslos und sicher abzuwickeln.

1. initializePayment(PaymentRequest-Anfrage):

• Betrachten Sie dies als den Beginn des Zahlungsvorgangs. Es sendet eine Anfrage mit allen Zahlungsdetails an das Zahlungsgateway.
• Es gibt ein PaymentSession-Objekt zurück, das Informationen wie die Zahlungs-URL und den Sitzungsstatus enthält.

2. holdInEscrow(String paymentId):

• Diese Methode sichert die Zahlung auf einem Treuhandkonto unter Verwendung der angegebenen Zahlungs-ID.
• Es stellt ein EscrowResponse-Objekt bereit, das alle Details zu den hinterlegten Geldern enthält.

3. releaseToProvider(String escrowId):

• Nachdem der Dienst erfolgreich aktiviert wurde, gibt diese Methode die Gelder vom Treuhandkonto an den Dienstanbieter frei.
• Die Treuhand-ID wird verwendet, um die richtigen Gelder zu identifizieren und freizugeben.

4. returnToCustomer(String escrowId):

• Wenn etwas schief geht, beispielsweise wenn die Aktivierung des Dienstes fehlschlägt, erstattet diese Methode dem Kunden das hinterlegte Geld zurück.
• Für die Bearbeitung der Rückerstattung wird die Treuhand-ID verwendet.

Hauptmerkmale:

• Die Klasse verwendet WebClient, um HTTP-Anfragen an die REST-API des Zahlungsgateways zu senden und so eine nahtlose Integration sicherzustellen.
• Es übernimmt wichtige Vorgänge wie das Starten von Zahlungen, die Verwaltung des Treuhandkontos und die Bearbeitung von Rückerstattungen.
• Alle Methoden verwenden synchrone Aufrufe (über .block()), um sicherzustellen, dass Vorgänge abgeschlossen sind, bevor sie fortfahren, und so die Zuverlässigkeit zu gewährleisten.

Dieser Kurs ist ein entscheidender Teil des Puzzles, wenn es um die Verwaltung sicherer und effizienter Finanztransaktionen im System geht.

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

Benachrichtigungs-DTOs

1. E-Mail-Benachrichtigung:

• Betrachten Sie dies als eine Blaupause für das Versenden von E-Mail-Benachrichtigungen. Es beinhaltet:
  • Die E-Mail-Adresse des Empfängers (an).
  • Der Betreff der E-Mail.
  • Eine Vorlagen-ID zur Bestimmung des Formats.
  • Dynamische Daten (templateData) zur Personalisierung des Inhalts.

2. SMS-Benachrichtigung:

• Ähnlich der E-Mail-Benachrichtigung, aber auf SMS zugeschnitten. Es beinhaltet:
  • Die Telefonnummer des Empfängers (phoneNumber).
  • Eine Vorlagen-ID für das Nachrichtenformat.
  • Dynamische Daten (templateData) zur Personalisierung.

Benachrichtigungsdienst

Dieser Dienst verwaltet alle an Benutzer gesendeten Benachrichtigungen über ihren Bestellstatus. So funktioniert es:

1. sendSuccessNotification(Bestellauftrag):

• Diese Methode verwaltet das Senden von Erfolgsbenachrichtigungen. Es verwendet:
  • buildSuccessEmail, um eine E-Mail-Benachrichtigung zu erstellen.
  • buildSuccessSms, um eine SMS-Benachrichtigung zu erstellen.
  • Es sendet auch Echtzeit-Updates über WebSocket mit QuotaWebSocketHandler.

2. sendFailureNotification(Order order):

• Dieser kümmert sich um Fehlerbenachrichtigungen. Es verwendet:
  • buildFailureEmail für E-Mail-Nachrichten.
  • buildFailureSms für SMS-Nachrichten.
  • Wie Erfolgsbenachrichtigungen sendet es auch WebSocket-Updates.

3. Hilfsmethoden:

• buildSuccessEmail und buildFailureEmail: Diese Methoden erstellen E-Mail-Benachrichtigungen basierend darauf, ob die Bestellung erfolgreich war oder fehlgeschlagen ist. Sie verwenden Vorlagen und die Details der Bestellung.
• buildSuccessSms und buildFailureSms: Diese machen dasselbe, jedoch für SMS-Benachrichtigungen.

Zusätzliche Funktionen:

• WebSocket-Updates: Hält das Front-End mithilfe von QuotaWebSocketHandler in Echtzeit auf dem neuesten Stand.
• Fehlerprotokollierung: Wenn etwas schief geht, werden die Fehler zum Debuggen protokolliert.

Dieser Dienst stellt sicher, dass Benutzer immer über ihre Bestellungen auf dem Laufenden sind, sei es per E-Mail, SMS oder Echtzeit-Updates.

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

QuotaUpdate-Klasse

• Stellen Sie sich diese Klasse als einen einfachen Messenger für Quotenaktualisierungen vor. Es enthält drei wichtige Informationen:
  • packageId: Die ID des Pakets, das aktualisiert wird.
  • availableQuota: Wie viel Kontingent für dieses Paket übrig bleibt.
  • Zeitstempel: Wann das Update durchgeführt wurde.

WebSocket-Konfiguration

1. WebSocketConfig:

• Dies ist das Setup, das die WebSocket-Kommunikation ermöglicht.
• Es registriert einen Handler (quotaWebSocketHandler), der unter /ws/quota auf WebSocket-Verbindungen wartet.
• Es ermöglicht auch Verbindungen von jedem Ursprung durch die Einstellung „allowedOrigins("*").

2. quoteWebSocketHandler():

• Dies definiert die WebSocket-Handler-Bean, die eingehende Nachrichten und Verbindungen verwaltet.

QuotaWebSocketHandler

Hier passiert die ganze WebSocket-Magie! Es verwaltet Echtzeitaktualisierungen zwischen dem Server und den Clients.

1. Felder:

• PackageCacheService: Hilft bei der Aktualisierung des lokalen Caches, wenn eine Kontingentaktualisierung eingeht.
• ObjectMapper: Verwaltet die Konvertierung von JSON-Nutzlasten in Java-Objekte und umgekehrt.
• Sitzungen: Verfolgt alle aktiven WebSocket-Sitzungen (derzeit verbundene Clients).

2. Methoden:

• afterConnectionEstablished(WebSocketSession-Sitzung):
  • Fügt eine neue Client-Sitzung zur aktiven Liste hinzu, sobald eine Verbindung hergestellt wird.
• afterConnectionClosed(WebSocketSession-Sitzung, CloseStatus-Status):
  • Entfernt die Clientsitzung, wenn die Verbindung getrennt wird.
• handleTextMessage(WebSocketSession-Sitzung, TextMessage-Nachricht):
  • Verarbeitet eingehende Nachrichten.
  • Konvertiert den empfangenen JSON in ein QuotaUpdate-Objekt und aktualisiert den lokalen Cache.

3. sendOrderUpdate(Bestellauftrag):

• Sendet Echtzeit-Updates über Bestelländerungen an alle verbundenen Kunden.
• Konvertiert das Order-Objekt in JSON und sendet es als Nachricht an aktive WebSocket-Sitzungen.
• Stellt sicher, dass nur offene Verbindungen Updates erhalten.

Hauptmerkmale des Kodex:

• Echtzeit-Updates:
  • Hält Kunden sofort über Kontingentänderungen und Auftragsaktualisierungen auf dem Laufenden.
• Thread-sichere Verwaltung:
  • Verwendet ConcurrentHashSet, um verbundene Clients zu verwalten und sicherzustellen, dass keine Konflikte entstehen, wenn mehrere Clients aktiv sind.
• Fehlerbehandlung:
  • Protokolliert Fehler, wenn beim Senden von Nachrichten ein Problem auftritt, was die Fehlerbehebung erleichtert.

Dieses Setup gewährleistet eine reibungslose und sofortige Kommunikation zwischen dem Backend und dem Frontend, sodass Benutzer immer über aktuelle Informationen zur Kontingentverfügbarkeit und zum Bestellstatus verfügen.

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

Hier finden Sie eine Aufschlüsselung dieser benutzerdefinierten Ausnahmeklassen und wie sie zur Behandlung bestimmter Fehlerszenarien im System verwendet werden:

QuotaNotAvailableException:

• Diese Ausnahme wird ausgelöst, wenn ein Benutzer versucht, ein Paket zu kaufen, das Kontingent für dieses Paket jedoch bereits aufgebraucht ist.
• Es kommt mit einer einfachen Standardmeldung: „Paketkontingent ist nicht verfügbar“, sodass sowohl Entwickler als auch Benutzer ein klares Verständnis des Problems erhalten.

OrderNotFoundException:

• Diese Funktion wird aktiviert, wenn das System anhand der angegebenen Bestell-ID keine Bestellung finden kann.
• Es enthält eine detaillierte Fehlermeldung wie „Bestellung nicht gefunden: [Bestell-ID]“, sodass Sie leicht genau feststellen können, welche Bestellung fehlt.

PaymentVerificationException:

• Wenn bei der Überprüfung einer Zahlung ein Problem auftritt – beispielsweise stimmen die Beträge nicht überein oder der Zahlungsstatus ist unklar – wird diese Ausnahme ausgelöst.
• Es ermöglicht Ihnen, eine benutzerdefinierte Nachricht zu übergeben, was Flexibilität und Kontext für die Diagnose von Zahlungsproblemen bietet.

Durch die Verwendung dieser Ausnahmen behandelt das System Fehler auf saubere und vorhersehbare Weise. Sie machen das Debuggen für Entwickler nicht nur effizienter, sondern stellen auch sicher, dass Benutzer klares und umsetzbares Feedback erhalten, wenn etwas schief geht.

// Request/Response DTOs
@Getter @Setter
public class OrderRequest {
    private String customerId;
    private String packageId;
    private BigDecimal amount;
}

@Getter @Setter
public class PaymentCallback {
    private String orderId;
    private String paymentId;
    private String status;
    private BigDecimal amount;
    private LocalDateTime timestamp;
}

@Getter @Setter
public class QuotaResponse {
    private String packageId;
    private boolean available;
    private Integer remainingQuota;
    private LocalDateTime timestamp;
}

@Getter @Setter
public class ReservationResponse {
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

@Getter @Setter
public class ActivationResponse {
    private String orderId;
    private boolean success;
    private String activationId;
    private String errorCode;
    private String errorMessage;
}

@Getter @Setter
public class VerificationResponse {
    private String orderId;
    private String activationId;
    private boolean success;
    private String status;
    private LocalDateTime activatedAt;
}

@Getter @Setter
public class PaymentRequest {
    private String orderId;
    private BigDecimal amount;
    private String currency;
    private String customerId;
    private String returnUrl;
    private String callbackUrl;
}

@Getter @Setter
public class PaymentSession {
    private String sessionId;
    private String paymentUrl;
    private LocalDateTime expiresAt;
    private String status;
}

@Getter @Setter
public class EscrowResponse {
    private String id;
    private String paymentId;
    private BigDecimal amount;
    private String status;
    private LocalDateTime createdAt;
}

Die OrderService-Klasse übernimmt die schwere Arbeit, wenn es um die Verwaltung von Bestellungen geht. Lassen Sie uns zusammenfassen, wie es funktioniert:

Hauptaufgaben

1. createOrder(OrderRequest-Anfrage):

   • Bei dieser Methode geht es darum, eine neue Bestellung zu erstellen. Es prüft, ob das Paket verfügbar ist, erfasst die Details, reserviert das Kontingent und speichert die Bestellung in der Datenbank mit dem Anfangsstatus RESERVIERT.

2. processPayment(String orderId, PaymentCallback Rückruf):

   • Hier wird die Zahlung abgewickelt. Das System überprüft die Zahlungsdetails, aktualisiert die Bestellung, hinterlegt die Zahlung auf einem Treuhandkonto und startet den Serviceaktivierungsprozess. Wenn etwas schief geht, werden Ausfälle elegant bewältigt.

3. verifyActivation(Order order):

   • Diese Methode überprüft noch einmal, ob die Dienstaktivierung reibungslos verlief. Es wird bis zu dreimal versucht, und wenn es immer noch fehlschlägt, greift das System zurück, um den Fehler zu beheben.

4. completeOrder(Bestellauftrag):

   • Sobald alles überprüft wurde, wird die Bestellung mit dieser Methode abgeschlossen. Es gibt die Treuhandgelder an den Anbieter frei, aktualisiert den Status und benachrichtigt den Benutzer über den Erfolg.

5. handleActivationFailure(Order order):

   • Wenn die Aktivierung fehlschlägt, stellt diese Methode sicher, dass der Kunde eine Rückerstattung und eine Benachrichtigung darüber erhält, was schief gelaufen ist.

6. getOrder(String orderId):

   • Diese einfache Methode ruft eine Bestellung anhand ihrer ID ab. Wenn die Bestellung nicht vorhanden ist, wird eine bestimmte Ausnahme ausgelöst.

Warum es funktioniert

• Dank seiner transaktionalen Natur stellt es sicher, dass Transaktionen entweder abgeschlossen oder rückgängig gemacht werden.
• Mit klarer Fehlerbehandlung und Wiederholungsversuchen ist es robust genug, um reale Probleme zu bewältigen.
• Benachrichtigungen halten Benutzer bei jedem Schritt auf dem Laufenden.

Dieser Service ist das Rückgrat des Auftragsverwaltungsprozesses und verbindet alles für ein nahtloses Benutzererlebnis.

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

Die OrderController-Klasse kümmert sich um die REST-API-Endpunkte, die Bestellungen im System verwalten. Think ist die Brücke zwischen dem Kunden, der Anfragen stellt, und den Backend-Diensten, die die schwere Arbeit erledigen.

Wichtige Endpunkte

1. POST /api/orders (createOrder):

   • Dieser Endpunkt übernimmt die Erstellung einer neuen Bestellung.
   • Das passiert:
     • Es nimmt eine Bestellanfrage vom Kunden entgegen.
     • Ruft OrderService.createOrder auf, um die Anfrage zu verarbeiten und die Bestellung zu erstellen.
     • Sendet zurück:
       • Eine 200 OK-Antwort mit der neu erstellten Bestellung, wenn alles gut geht.
       • Ein 409-Konflikt, wenn das Paketkontingent nicht verfügbar ist.
       • Ein 500 Internal Server Error für unerwartete Probleme.

2. POST /api/orders/callback (handlePaymentCallback):

   • Dieser verarbeitet Zahlungsaktualisierungen, die vom Zahlungsgateway gesendet werden.
   • Hier ist der Ablauf:
     • Es erhält einen PaymentCallback mit allen Zahlungsdetails.
     • Ruft OrderService.processPayment auf, um die Zahlung abzuwickeln und den Bestellstatus zu aktualisieren.
     • Die möglichen Antworten sind:
       • 200 OK, wenn die Zahlung erfolgreich abgewickelt wurde.
       • 404 Nicht gefunden, wenn die angegebene Bestell-ID nicht existiert.
       • 422 Nicht verarbeitbare Entität, wenn bei der Zahlungsüberprüfung eine Abweichung vorliegt.
       • 500 Interner Serverfehler für etwas Unerwartetes.

3. GET /api/orders/{orderId} (getOrder):

   • Dieser Endpunkt ruft die Details einer bestimmten Bestellung anhand seiner ID ab.
   • So funktioniert es:
     • Es ruft OrderService.getOrder auf, um die Bestellung abzurufen.
     • Rücksendungen:
       • Eine 200-OK-Antwort mit den Bestelldetails, falls gefunden.
       • A 404 Nicht gefunden, wenn die Bestell-ID mit keinem Datensatz übereinstimmt.

Merkmale

• Trennung von Belangen: Der OrderController delegiert die gesamte Geschäftslogik an den OrderService und sorgt so dafür, dass die Dinge sauber und konzentriert bleiben.
• Validierung: Anforderungsnutzdaten werden mithilfe der @Valid-Annotation validiert, um sicherzustellen, dass die eingehenden Daten den Erwartungen entsprechen.
• Fehlerbehandlung:
  • Bietet spezifische und hilfreiche Antworten auf häufige Probleme, wie nicht verfügbare Kontingente oder fehlende Bestellungen.
  • Protokolliert alle Probleme, um das Debuggen zu erleichtern.
• Protokollierung: Verfolgt wichtige Ereignisse wie eingehende Anfragen, Fehler und Bestelldetails für eine bessere Sichtbarkeit.

Dieser Controller sorgt dafür, dass Client und Backend nahtlos kommunizieren und die Auftragsverwaltung so reibungslos wie möglich verläuft.

Abschluss

Diese Forschungsdokumentation legt die Grundlage für die Gestaltung eines E-Commerce-Kreditverkaufssystems und bewältigt wichtige Herausforderungen wie Quotenverwaltung, Zahlungsabwicklung und Serviceaktivierung. Während dieses Design die Grundlagen abdeckt, gibt es immer Raum für Verbesserungen!

Hier sind ein paar Ideen, um dieses Design zu verbessern:

• Verwenden Sie ereignisgesteuerte Architektur, um das System flexibler und skalierbarer zu machen.
• Fügen Sie Nachrichtenwarteschlangenbasierte Verarbeitung hinzu, um viele Transaktionen reibungslos abzuwickeln.
• Entdecken Sie erweiterte Caching-Strategien, um die Arbeit zu beschleunigen und die Abhängigkeit von externen APIs zu verringern.
• Berücksichtigen Sie verteilte Systemmuster für eine einfachere Skalierung und bessere Zuverlässigkeit.
• Implementieren Sie Leistungsschalter, um Störungen bei Drittanbieterdiensten reibungslos zu bewältigen.
• Richten Sie Überwachung und Warnungen ein, um Probleme frühzeitig zu erkennen und schnell zu beheben.
• Stärken Sie Sicherheitsmaßnahmen, um Benutzer und ihre Daten zu schützen.

Vielen Dank fürs Lesen! Ich hoffe, diese Dokumentation war nützlich und bietet Klarheit für alle, die sich mit ähnlichen Herausforderungen befassen. Natürlich ist dieses Design nicht perfekt – es gibt immer Raum für Verbesserungen. Wenn Sie irgendwelche Gedanken oder Vorschläge haben, würde ich sie gerne hören.

Ressourcen:

• Ein tiefer Einblick in saubere Architektur und SOLID-Prinzipien
• Entwerfen Sie E-Commerce-Anwendungen mit Microservices-Architektur
• Entwerfen eines skalierbaren Backends für Flash Sales
• Treuhandkonto auf Wikipedia

Das obige ist der detaillierte Inhalt vonEntwerfen eines Internet-Kreditkaufsystems. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!