Diese Seite listet auf, welche Videos in naher oder fernerer Zukunft geplant sind.
Die nachfolgende Liste ist nicht geordnet. Ich gebe keine Garantie ab, dass die Videos in naher oder ferner Zukunft kommen. Aber das sind Themen, die mir sinnvoll erscheinen. Feedback ist willkommen. Wer eigene Ideen für Videos einbringen - bitte am besten per Discord in den entsprechenden Veranstaltungs-Kanal posten! Ersatzweise per Email an stefan.bente@th-koeln.de.
BTW - wir hatten heute eine Diskussion im Workshop zu dem Thema “Transaktionsgrenzen”, und dass in lose gekoppelten Systemen (Modulithen oder Microservices) die Transaktionsgrenzen auf den Aggregates liegen müssen. Das wiederum hat zur Folge, dass man auch damit rechnen muss, mal Dinge rückgängig machen zu müssen. Beispiel: Wenn der Kunde Sachen bestellt, man aber feststellt, dass man die Waren DOCH nicht mehr hat.
Mein Aussage war, dass das eigentlich auch vor dem digitalen Zeitalter schon so war, und dass die kaufmännische Branche “Hintertüren” einbaut, damit man Dinge nochmal rückgängig machen kann. Ganz konkret ging es dann um die Frage, was genau der Klick auf den “Kaufen” Button bedeutet. Ist das schon der Vertragsabschluss?
Jetzt mit Beleg: NEIN, ist es nicht. Der “Kaufen” Button ist i.d.R. ein sog. “invitatio ad offerendum”:
“Ist die Präsentation von Ware auf einer Website bereits ein juristisches Angebot, gerichtet auf Abschluss eines Vertrages ? Die Konsequenz wäre, dass der Käufer bereits durch das Drücken eines Bestellbuttons das Angebot annehmen kann und folglich ein Vertrag zustande gekommen wäre. Wenn der Anbieter die bestellte Ware dann nicht liefern kann, etwa weil sie ausverkauft ist, würde er sich unter Umständen schadensersatzpflichtig machen. Dies ist die Problematik der sog. “invitatio ad offerendum”, also der Aufforderung an den Kunden, ein Angebot abzugeben. Das Anbieten einer Leistung oder Ware auf einer Website stellt in der Regel noch kein Angebot auf Vertragsschluss dar, sondern ist eine Aufforderung zur Abgabe eines Angebotes an den Kunden. (https://www.e-recht24.de/ecommerce/11-vertragsschluss-im-internet.html)
Und ich habe mal zufällig in zwei AGBs geschaut.
Ihre Bestellung stellt ein Angebot an Amazon zum Abschluss eines Kaufvertrages dar. […] [Die] Bestellbestätigung stellt keine Annahme Ihres Angebotes dar, sondern soll Sie nur darüber informieren, dass Ihre Bestellung bei uns eingegangen ist. Ein Kaufvertrag kommt erst dann zustande, wenn wir das bestellte Produkt an Sie versenden und den Versand an Sie mit einer zweiten E-Mail oder einer Nachricht in Ihr Message Center in Ihrem Kundenkonto (Versandbestätigung) bestätigen.
Du gibst mit deiner Bestellung ein Angebot zum Abschluss eines Kaufvertrages ab. Der Eingang deines Auftrages wird dir schriftlich (per Post oder E-Mail) bestätigt. Der Kaufvertrag wird dann 5 Werktage nach Eingang deiner Bestellung verbindlich geschlossen, ohne dass es hierfür einer weiteren Erklärung bedarf.
Auswertung der Bachelorarbeit von TdJ zu dem Thema.
ST2M4_Seiteneffekte_in_getContributingDepotsForOrder.zip
Meine Analyse auf Discord dazu:
Sie haben da einen grundlegenden Designfehler drin. Die Order wird via Methode
getContributingDepotsForOrder(orderId) fulfilled. Eine get... Methode hat
Seiteneffekte! Nämlich dass Sachen aus dem Lager genommen werden.
Und laut meinem Debugger wird die Methode mehrfach gerufen:
getContributingDepotsForOrder(orderId) ruft
getContributingDepotsForOrder(orderId, depotId), und die ruft dann nochmal
getContributingDepotsForOrder(orderId). Beim zweiten Mal kann die Order dann
nicht mehr fulfilled werden - das Lager ist leer 😦.
Das müssen Sie bitte SOFORT ändern, sonst fliegt Ihnen das immer wieder um die Ohren.
Das Fulfillment der Order MUSS in dem Moment passieren, wo die Order erstellt wird.
Nicht in dem Moment, wo man mit get... draufzugreift.
Wenn das bei Ihnen Zykel erzeugt: Dann kann man immer noch das Fulfillment anstoßen, wenn es noch keine GESPEICHERTEN Shipments gibt. Und dann bei den nächsten Aufrufen von getContributingDepotsForOrder prüfen, ob es schon was Gespeichertes gibt, und das dann zurückgeben.
Warum hält denn die ShipmentUnit (die Domain-Klasse) keinen Verweis auf zugehörige Order und
das zugehörige Depot ? Da fängt das ganze Elend an 😕. Sie müssen das richtig refactoren.
Die ShipmentUnit Klasse darf nicht leer sein. Sonst können Sie die ShipmentUnits für Order und
Depot nicht nachhalten.
Ich vermute, Sie haben die Klasse leer gemacht, weil es beim Delete Probleme mit Foreign Key Violations gab - richtig? Da ist aber auch Ihre deleteAllShipmentUnits() Methode falsch:
@Override
public void deleteAllShipmentUnits() {
depotRepository.deleteAll();
}
Warum werden hier Depots gelöscht und nicht Shipments?
Any presentation you’ll give lateron, be it in your professional life before a customer, at a conference, or in the Master colloquium - a good demo of actual code is often what sets a presentation apart from others. A demo needs a storyboard, it should tell a little story, and it needs to be paced well.
(Diese Planung ist noch tentativ und kann sich ändern.)
Ein 20 Jahre altes Buch, das immer noch aktuell ist. Wieso?
Auswertung der Bachelorarbeit und des ggfs. zu erstellenden Papers zu dem Thema.