Child pages
  • ST2-Workshop am 12.07.2021 (Wiederholung, Klausurvorbereitung)


ST2-Workshop am 12.07.2021 (Wiederholung, Klausurvorbereitung)

Agenda

Ergebnis der Umfrage

An der vorbereitenden Umfrage haben 12 Studierende teilgenommen - ich weiß also nicht, wie repräsentativ die Ergebnisse sind. 

Das Ergebnis ist aus meiner Sicht nicht ganz eindeutig. Folgendes habe ich für die Übung rausgezogen: 

  • Clean Code, Domain Primitives und REST-API-Regeln scheinen eher verstanden zu sein. 
  • SOLID, Aggregates und Implementierung wird eher als schwierig empfunden. 

Bitte stellen Sie am Montag Fragen, wenn Sie noch grundsätzliche Verständnisprobleme haben. Ich versuche, das Spektrum in Übungsaufgaben noch einmal aufzugreifen. 

Offene Fragen

Folgende Fragen wurden in der Umfrage und im Discord gestellt. 

Zur Klausur:

  1. Ich würde mir wünschen, das besonders auf den Umfang der Klausur eingegangen wird. Dazu habe ich nämlich auch Bedenken, wie die Klausur zeitlich eingeteilt wird.
  2. Wird es in der Klausur Unit Test geben oder sollen wir diese selbst implementieren?
  3. Wird die kommende ST2 Klausur genauso wie die Vorherige aufgebaut sein?
  4. Wird uns zusätzlich Zeit gegeben, um bei auftretende Probleme etwas debuggen zu können?
  5. Wird es im Klausur Repo eine vordefinierte Package Struktur geben?
  6. Welche Code Abschnitte werden bereits implementiert sein?
  7. Wie viel Zeit steht uns maximal zur Verfügung?
  8. Wie viele Aufgaben wird es insgesamt geben?
  9. Wie viel Zeit benötigt man durchschnittlich für jede Aufgabe?
  10. Oder anders gefragt, wie lange sollten man maximal für jede Aufgabe Zeit investieren, um rechtzeitig fertig zu werden?

Fachlich: 

  1. Lege ein neues Treffen einer Lerngruppe zum Thema „ST2“ an. plannedmeeting ist hier eine Entity.
    1. Als erste Frage brauchen Entity unbedingt ID? wenn Ja, könnten wir so etwas haben: PUT / studyGroups/{s-id}/plannedMeetings/{p-id}/ST2??.
    2. oder da es nur ein Meeting pro Topic gibt, spielt die {Topic} als ID für die Plannedmeeting nur bei dieser Aggregate mit root StudyGroup?
    3. Wenn ZB plannedmeeting ein VO wäre, könnte ich ganz schnell verstehen, warum es keine ID braucht. Dann da es eine Entity ist, bin ein bisschen verwirrt(Bearbeitet)
  2. Jetzt über REST Implementierung: Bei PUT, handelt sich nur um genau eine Item. fast das gleich Frage für DELETE ? wenn ich hier statt, PUT item on a Field. Kann/darf ich auch mit POST machen? zb @PostMapping("/dungeons/{dungeonId}/fields/{fieldId}/items")
  3. Können wir eine Dto von VO erstellen?

Übung

Für die Übung gibt es zwei Repos. 

Es ist ein kleines Beispiel (4 Klassen, 200 Zeilen Code insgesamt). Es geht um folgendes: 

  • Wir betrachten das Payment-Modul eines Webshops. Der Shop operiert in Deutschland, NL, Belgien, Österreich, Dänemark und Schweden. Er unterstützt also die Währungen EUR, DKR und SEK. 
  • Es gibt Kunden, die Rechnungen (Invoice) bekommen, für bestellte Waren. Kunden haben nur Vor- und Nachname sowie eine Email. Es gibt noch Firmenkunden, die nur einen Namen und eine Email haben. 
  • Umtausch auf Kulanz wird durch die Ausgabe von Gutscheinen (Voucher) geregelt. Diese sind personalisiert. Man kann Bestellungen mit solchen Vouchers bezahlen. Man kann die Vouchers auch mehrmals einsetzen, so lange, bis der Geldbetrag darauf verbraucht ist. 

Sie sollen folgendes tun:

  1. Wenden Sie Clean-Code-Regeln an. 
  2. Nutzen Sie die SOLID-Prinzipien, um den Code zu verbessern. 
  3. Implementieren Sie Domain Primitives. 
  4. Identifizieren Sie Entities, Value Objects und Aggregates.
  5. Implementieren Sie dies mit JPA. 
  6. Spezifizieren Sie ein REST-API. 
  7. Implementieren Sie das REST-API. 

Die nachfolgenden Aufgaben leiten Sie durch den Prozess. Die Reihenfolge ist ein kleines bisschen abgewandelt, damit es einfacher und nachvollziehbarer ist. 

E1) Clean Code - Meaningful Names

Sorgen Sie für "Meaningful Names", damit der Code ein bisschen weniger wirr ist. 

E2) Domain Primitives

Man kann im Code mindestens drei Domain Primitives finden. Implementieren Sie diese und sorgen Sie für ein entsprechendes Refactoring im Code. 

E3) Annotieren Sie die Verletzungen der folgenden Clean-Code-Regeln und SOLID-Prinzipien im Code

Machen Sie bitte in den Code, wie er sich jetzt darstellt, einfach mal "Marker" (als Kommentare) der folgenden Form, um Verletzungen von Clean-Code-Regeln und SOLID-Prinzipien anzuzeigen. 

//**  CC - no side effects

//**  CC - keep your methods small

//**  CC - proper error handling

//**  SOLID - single-responsibility-principle

//**  SOLID - open-closed-principle

//**  SOLID - liskov-substitution-principle

E4) Führen Sie ein Refactoring durch, um die Erkenntnisse aus E3 umzusetzen

... sollte klar sein.

E5) Identifizieren Sie Entities, Value Objects und Aggregates

Erstmal würde das als logisches Datenmodell genügen, in dem E, VO und AR als Annotationen drin sind, und die Aggregates umkringelt sind. Attribute brauchen nicht dargestellt zu werden, VOs sollten als eigene Klassen abgebildet werden.

E6) Setzen Sie die Struktur aus E5 entsprechend mit Spring Data JPA persistent um

... sollte klar sein.

E7) Spezifizieren Sie REST-Endpoints 

Spezifizieren Sie REST-Endpoints für folgende Aufgaben:

  1. Lege Kunde neu an
  2. Hole Liste aller Kunden
  3. Zeige einen Kunden an
  4. Ändere die Email eines Kunden
  5. Lege eine Rechnung neu an
  6. Zeige eine bestimmte Rechnung an
  7. Suche alle Rechnungen für einen Kunden
  8. Lösche eine Rechnung
  9. Lege einen Voucher neu an
  10. Finde Vouchers, die für einen bestimmten Zweck eingelöst wurden
  11. Finde alle Vouchers einer Währung und >0 Geld drauf für einen Kunden
  12. Bezahle Rechnung mit einem Voucher

E8) Implementieren Sie obigen Endpoints