Wie findet ihr die Diagramme und was könnte man besser machen?

[osion]

Guten Abend

Ich musste für die Uni unter anderem verschiedene Diagramme für einen Microservice erstellen, über die ich bald mündlich geprüft werde. Bei dieser Prüfung geht es auch darum, was man hätte besser machen können. Nun habe ich die Diagramme so oft gesehen, dass mir die Objektivität fehlt. Deswegen frage ich mich, was Ihrer Meinung nach an den vorgestellten Diagrammen verbesserungswürdig ist und was fehlt.

Ich bin dankbar für jeden konstruktiven Beitrag.

 

[Marinek]

Also das Domain Modell sieht komisch aus. Ist es für eine Datenbank fehlen Bezeichnungen wie FK und PK.

Ist es ein Klassendiagramm so sind die eingezeichneten FKs überflüssig, da ich diese gerade aus dem Modell lesen kann. Dann fehlen aber Methoden.

Wenn ein Employee zwei Rollen hat, kannst du das nicht abbilden.

Außerdem kann eine beliebige Rolle angegeben werden. Üblicherweise gibt es aber ein Set an Rollen.

Warum hat die Order eine id und eine ordernumber? Wo ist der unterschied?

Warum ist da überall eine branchID. Mindestens bei delivery macht es keinen Sinn.

Hier hast du bei Articels eine Liste vorgehen. Warum ist in den anderen Entitäten dann custermerID. Ichs vom typ Customer?

Zu dem Microservice: Warum ist den Order Customer get asynchrone?

 

[osion]

Zuerst mal danke für die Rückmeldung


Also das Domain Modell sieht komisch aus. Ist es für eine Datenbank fehlen Bezeichnungen wie FK und PK.
Das fiktive Beispiel ist:
Der Kunde hat ein Bestellsystem für seine dezentralen Filialen bestellt. Jede Filiale hat ein eigenes
lokales Lager, welches ein lokales Sortiment verwaltet. Für alle Filialen gemeinsam existiert ein
zentrales Lager. Dieses wird in einem bestehenden System (Legacy System) verwaltet, und soll über
eine (gelieferte) klassische, class-based Java- API eingebunden werden.
Im zentralen Lager sind die Artikel entweder sofort lieferbar oder haben eine Lieferfrist. Die einzelnen
Artikel werden ausschliesslich über eine Artikelnummer identifiziert (keine Artikel-Bezeichnung, kein
Artikelsortiment). Die Buchhaltung inkl. Mahnwesen für die Rechnungserstellung und -behandlung ist
nicht Teil dieses Projektes, die Integration muss aber entworfen werden.

Das Domain Modell ist für das ganze System, welches wir entwickeln mussten.

Wenn ein Employee zwei Rollen hat, kannst du das nicht abbilden.
Außerdem kann eine beliebige Rolle angegeben werden. Üblicherweise gibt es aber ein Set an Rollen.

Es wäre besser gewesen, ein Set von Rollen zu machen, statt nur eine Rolle.

Warum ist da überall eine branchID. Mindestens bei delivery macht es keinen Sinn.
Hier hast du bei Articels eine Liste vorgehen. Warum ist in den anderen Entitäten dann custermerID. Ichs vom typ Customer?

BranchId ist überall enthalten, weil alles der BranchId zugeordnet werden muss. Das mit CustomerID vom Typ Customer habe ich nicht gefunden.

Zu dem Microservice: Warum ist den Order Customer get asynchrone?

Die Bestellung wird entgegengenommen und anschließend werden die Artikeldaten sowie die Kundendaten asynchron von den zuständigen Microservices angefragt. Ist das schlecht?

 

[Marinek]

BranchId ist überall enthalten, weil alles der BranchId zugeordnet werden muss. Das mit CustomerID vom Typ Customer habe ich nicht gefunden.

Nein, so funktioniert das nicht. Wenn ich ein Lager habe, dann muss ich wissen zu welcher Filiale (branchID) das gehört. Alle Artikel, die in diesem Lager sind, haben die gleiche branchID wie das Lager. Also ist die Angabe mind. Redundant und das ist schlecht.

Das fiktive Beispiel ist:

Hier muss man nun genau lesen. Hier ist von Customer (Kunde) gar keine Rede. Warum wird das dann modelliert? Es ist ein Warenwirtschaftssystem innerhalb einer Organisation. Der Kunde ist ja der Besteller. Also entweder die zielfiliale oder der Angestellte.

Jede Filiale hat ein eigenes
lokales Lager, welches ein lokales Sortiment verwaltet.

Das sehe ich falsch modelliert. Üblicherweise will ich doppeleingaben verhindern in einem Software System. Hier wäre also der Artikel vom Sortiment zu trennen.

Wenn zwei Filialen den gleichen Artikel haben, dann müssen beide diesen neu eingeben.

Und was passiert wenn der eine Artikel von Zentrallager an Filiale geliefert wird. Wie soll man das zusammenfügen?

Also das ist nicht sauber.

Das mit CustomerID vom Typ Customer habe ich nicht gefunden.

Du hast eine Entität Order.

Darin ist eine Customer ID vom Typ Long. Das ist falsch. Denn hier müsste sowas stehen wie Custimer vom Typ Customer. Analog wie du es bei delivery gemacht hast.

Gleichzeitig ist das eine redundante Angabe weil. Ich das anhand der Assoziation sehen kann.

Möglicherweise bisschen ungenau weil ich ich die Richtung der Assoziation nicht erkenne. Du möchtest bidirektional. Dann fehlen da noch Pfeile.

Die Bestellung wird entgegengenommen und anschließend werden die Artikeldaten sowie die Kundendaten asynchron von den zuständigen Microservices angefragt. Ist das schlecht?

Also hier müssen wir unterscheiden zwischen den Prozessen innerhalb eines Microservices und zwischen den microservices.

Ich als Benutzer möchte ja ein Feedback haben: deine Bestellung ist durch. Klar in meinem Browser oder App dreht sich eine Eieruhr und ich warte. Und das kann asynchrone sein.

Aber die Aufgabe einer Bestellung kann das nicht. Denn ich will ja nicht 10 Minuten auf die Antwort warten. Bis der microservices soweit ist meine Anfrage zu beantworten. Sondern sofort.

Beim log ist das richtig. Da schicke ich. Eine Nachricht und dann egal. Aber das einholen von Kunden Informationen. Und Artikel muss synchrone passieren. Weil ich im Zweifel eine Reihenfolge habe. Wenn der Kunde nicht da ist, dann bringen mir die Artikel Nix.

 

[mrBrown]

Zum Domain Model:

Jede Filiale hat ein eigenes lokales Lager, welches ein lokales Sortiment verwaltet. Für alle Filialen gemeinsam existiert ein
zentrales Lager. Dieses wird in einem bestehenden System (Legacy System) verwaltet, und soll über
eine (gelieferte) klassische, class-based Java- API eingebunden werden.
Im zentralen Lager sind die Artikel entweder sofort lieferbar oder haben eine Lieferfrist. Die einzelnen
Artikel werden ausschliesslich über eine Artikelnummer identifiziert (keine Artikel-Bezeichnung, kein
Artikelsortiment). Die Buchhaltung inkl. Mahnwesen für die Rechnungserstellung und -behandlung ist
nicht Teil dieses Projektes, die Integration muss aber entworfen werden.

Da fehlt ein bisschen was, oder?

So rein aus dem Text kommt man zu ~4 Entitäten die Teil deiner Domäne sind (je nachdem wie man die Lager modelliert, ob man Sortiment noch mal extra sieht, etc), in deiner Grafik kommen mindestens acht vor, wobei sich die aus dem Text nicht alle eindeutig wiederfinden lassen.

Macht's ein bisschen schwierig, dass Domänen-Modell zu beurteilen, wenn man die Domäne gar nicht kennt


Generell: Die meisten IDs können wahrscheinlich weg, entweder sollten die eine Assoziation sein oder sie existieren fachlich nicht und sind nur technisch nötig. Die Assoziationen könnten etwas genauer sein, "has" z.B. ist so ein typischer Informatiker-Name, den fachlich niemand nutzen würde.


Zum Mikroservice-Modell:

Fehlt wieder so ein bisschen der Usecase, daher nur generell:

• Als Anstatt der Queue würde ich fachliche Events nutzen, macht es mMn oft verständlicher
• Bei allem asynchronem Get-Return kann man sich überlegen, ob es so das sinnvollste ist oder ob es bessere Wege gibt. Sollte man dann im Idealfall sinnvoll begründen können, warum man es so gewählt hat
• Die Bezeichnung der Services sieht ein bisschen nach "Ein Service pro Entität" statt "Ein Service pro fachlichem Prozess/Bounded Context" aus, ist aber schwierig zu sagen wenn man nur das Bild sieht ohne weitere Erklärung und die Domäne nicht kennt

Zu Bounded Contexts:

Bounded Contexts sollten Teil der Domäne sein, wenn man die dort schon sauber einführt kann man meist leichter darauf aufbauend sinnvolle Micro-Services designen.

Würde tatsächlich, falls das noch sinnvoll & möglich ist, mit Bounded Contexts startend das Domänen-Modell teilweise neu aufbauen und damit dann Micro-Services designen. (Ist natürlich viel Aufwand, der u.U. nicht mehr lohnt, macht aber vielleicht Dinge verständlicher)

 

[mrBrown]

Ich als Benutzer möchte ja ein Feedback haben: deine Bestellung ist durch. Klar in meinem Browser oder App dreht sich eine Eieruhr und ich warte. Und das kann asynchrone sein.

Aber die Aufgabe einer Bestellung kann das nicht. Denn ich will ja nicht 10 Minuten auf die Antwort warten. Bis der microservices soweit ist meine Anfrage zu beantworten. Sondern sofort.

Beim log ist das richtig. Da schicke ich. Eine Nachricht und dann egal. Aber das einholen von Kunden Informationen. Und Artikel muss synchrone passieren. Weil ich im Zweifel eine Reihenfolge habe. Wenn der Kunde nicht da ist, dann bringen mir die Artikel Nix.

Das kann man auch asynchron sauber umsetzen. Der Prozess muss es nur fachlich auch hergeben - das ist aber tatsächlich bei ziemlich vielen der Fall.

Schon mal nen Kaffee bei Starbucks in nem modernen McDonalds bestellt?

 

[osion]

Danke für die Rückmeldungen. In 45 Minuten habe ich meine Prüfung