Fragen zur Software-Architektur

[temi]

Hallo zusammen,

ich habe einige Fragen zur Softwarearchitektur bei denen ich mir trotz viel Recherche nicht sicher bin, ob ich das richtig handhaben möchte.

Es geht um eine Lagerverwaltung, d.h. es sollen Artikel die in unterschiedlichen Lagern liegen gesucht und ein-/ausgebucht werden können.


Damit es jetzt nicht zu umfangreich wird nur ein kleiner Auszug daraus und ich beginne auf der "Datenseite". Nehmen wir an es gibt die Datenbanktabellen "ItemTable" (die Artikel) und "BaseUnitTable" (die Mengeneinheit eines Artikels). Daten im ItemTable halten einen Fremdschlüssel auf die zugehörige BaseUnit. Weitere Tabellen wären z.B. StorageTable (Lager), ItemStockTable (in den Lagern gelagerte Artikel) usw.

In einem zugehörigen Domänenmodell gäbe es jetzt entsprechende Klassen (Aggregate? Entities?) "Item" und "BaseUnit", wobei ein Item ja auch eine BaseUnit hat.

Außerdem in der Datenzugriffsschicht die Repositories "ItemRepository" und "BaseUnitRepository" (wobei vom ItemRepository ebenfalls die zugehörige BaseUnit mitgeliefert wird, aber zur Stammdatenpflege von BaseUnits müssen diese auch unabhängig verfügbar sein). Viel Geschäftslogik wird es in diesen beiden Klassen nicht geben. Bei weiteren Domänenklassen, die z.B. Lagerbuchungen verwalten ist das dann spätestens der Fall.

Auf der UI-Seite haben wir sowas wie

"EditItemView.fxml" + "EditItemView.css" + "EditItemController.java"
"EditBaseUnitView.fxml" + "EditBaseUnitView.css" + "EditBaseUnitController.java"

Ist das soweit erst mal korrekt?

Die Controller benötigen ja nicht unbedingt Klassen aus dem Domänenmodell, sondern ggf. Datenobjekte mit speziell zusammengestellten Inhalten, z.B. eine Tabelle von Artikeln mit ihren Beständen in den unterschiedlichen Lagern.

Ist das so richtig, dass die UI-Schicht ihre eigenen Datenklassen für ihre Belange definiert?

Woher erhält die UI-Schicht diese Daten? Gibt es dafür noch eine zusätzliche Schicht zwischen UI und Domäne und wie wird diese im Normalfall realisiert? Oder greift die UI direkt auf Domänenobjekte zu?

Ich hoffe es findet sich jemand, der meine Fragen beantworten kann und bedanke mich schon mal dafür

Gruß,
Temi

 

[temi]

Ich habe mal eine kleine Skizze dazu angefertigt und noch einen zusätzlichen Layer "Services" eingefügt. Demnach könnte die UI über einen (mehrere) Service z.B. "getItemListWithStorageAndStock" oder "insertNewItem" auf die darunter liegenden Daten zugreifen, die gesuchten Daten aus den Repositories anfordern und ggf. auf UI-DTOs mappen. Korrekt so?

 

[mrBrown]

Im wesentlichen klingt das passend.

Service kann man aber in dem Fall in zwei Service-Layer teilen: einmal Services im Domain-Layer, die dann auch Domänen-Logik enthalten, und einmal Application-Layer, welches die Logik der Applikation und auch das Mapping von Domäne<->DTO enthält, aber eben keine Domänen-Logik.

In einem zugehörigen Domänenmodell gäbe es jetzt
entsprechende Klassen (Aggregate? Entities?) "Item" und "BaseUnit", wobei ein Item ja auch eine BaseUnit hat.

Aus der knappen Beschreibung schwierig abzuleiten, aber spontan wäre Item ein Aggregate (und damit auch Entity), und BaseUnit könnte ein Value-Object sein (wenn es denn eine "Einheit" darstellt) oder eben auch eine Entität oder sogar Aggregate - hängt von der Verwendung ab

Außerdem in der Datenzugriffsschicht die Repositories "ItemRepository" und "BaseUnitRepository" (wobei vom ItemRepository ebenfalls die zugehörige BaseUnit mitgeliefert wird, aber zur Stammdatenpflege von BaseUnits müssen diese auch unabhängig verfügbar sein). Viel Geschäftslogik wird es in diesen beiden Klassen nicht geben. Bei weiteren Domänenklassen, die z.B. Lagerbuchungen verwalten ist das dann spätestens der Fall.

Repositorys sollten generell keine Geschäftslogik enthalten, die gehört in Domänenobjekte und Services, sondern nur Speichern, Laden und Suchen

 

[temi]

Aus der knappen Beschreibung schwierig abzuleiten, aber spontan wäre Item ein Aggregate (und damit auch Entity), und BaseUnit könnte ein Value-Object sein (wenn es denn eine "Einheit" darstellt) oder eben auch eine Entität oder sogar Aggregate - hängt von der Verwendung ab

Die beiden Datenbanktabellen würden ungefähr so aussehen:

//ItemTable
UID id
String shortName
String description
UID fkBaseUnit

//BaseUnit
UID id
String shortName // z.B. "ST"
String description // z.B. "Stück"
int decimals // Anzahl der Nachkommstellen, im Beispiel "0"

BaseUnit legt sozusagen fest, wie Ein-/Ausbuchungen verrechnet, bzw. angezeigt werden (z.B. damit man nicht nur ganze Meter ausbuchen kann), ist aber im Prinzip immutabel.

Da wäre auch gleich eine Frage, BaseUnit hat ja allein für die DB eine Identität (die id). Macht es das allein schon zum Entity? Dürfte ja eigentlich nicht so sein, weil sonst ja grundsätzlich alles was in der DB gespeichert wird ein Entity wäre.[/code]

 

[temi]

Repositorys sollten generell keine Geschäftslogik enthalten, die gehört in Domänenobjekte und Services, sondern nur Speichern, Laden und Suchen

Ja, war von mir falsch formuliert, bzw. im falschen Zusammenhang. Aber dafür gleich noch eine Frage: Wo "leben" denn die Domänenobjekte? Im Repository?

Ich hoffe man versteht die Frage: Die Domänenobjekte sind ja nicht einfach so da. In der Software sind sie ja auch in einer Collection gespeichert, die irgendwo enthalten ist.

 

[temi]

Service kann man aber in dem Fall in zwei Service-Layer teilen: einmal Services im Domain-Layer, die dann auch Domänen-Logik enthalten, und einmal Application-Layer, welches die Logik der Applikation und auch das Mapping von Domäne<->DTO enthält, aber eben keine Domänen-Logik.

Könnte man dann sagen:
Der Domain-Layer enthält Domänenobjekte, Domain-Services und Repositories.
Der Application-Layer enthält DTOs, UI-Controller und UI-Services.
Der Application-Layer ist demnach zusammen mit den deklarativen Teilen (fxml, css) die eigentlich ausgeführte Applikation (und womöglich im Gesamtprojekt ein separates Unterprojekt)?

Würde man die speziell für die UI bestimmten Datenobjekte korrekt als DTO bezeichnen, oder anders?

 

[mrBrown]

BaseUnit legt sozusagen fest, wie Ein-/Ausbuchungen verrechnet, bzw. angezeigt werden (z.B. damit man nicht nur ganze Meter ausbuchen kann).

Da wäre auch gleich eine Frage, BaseUnit hat ja allein für die DB eine Identität (die id). Macht es das allein schon zum Entity? Dürfte ja eigentlich nicht so sein, weil sonst ja grundsätzlich alles was in der DB gespeichert wird ein Entity wäre.

So in etwa ist es. Ergibt sich die Identität aus der ID -> Entity. (Werte können sich ändern, es ist aber das gleiche)
Ergibt sich die Identität aus den Werten -> Value-Object. (Wenn die Werte sich ändern, ist es was anderes)

Bei der Verwendung von DBs vermischt sich das leider schnell schnell. Leichter macht man das, wenn man dabei alle Spalten immutable macht.

BaseUnit dürfte ein Value-Object sein: Wenn man irgendwas ändert, ist es ja eine andere Unit.

Ja, war von mir falsch formuliert, bzw. im falschen Zusammenhang. Aber dafür gleich noch eine Frage: Wo "leben" denn die Domänenobjekte? Im Repository?

Jein, es ist eher ein Wann als ein Wo.
Stell dir ein Repo als eine Collection vor, du kannst Werte reinlegen und rausnehmen, wie bei einer Liste.
Das lebt, bevor es drin ist, das lebt, solange es drin ist, das lebt wenn du es wieder rausnimmst, das lebt, bis du es irgendwann explizit "tötest".

Könnte man dann sagen:
Der Domain-Layer enthält Domänenobjekte, Domain-Services und Repositories.
Der Application-Layer enthält DTOs, UI-Controller und UI-Services.

Würde man die speziell für die UI bestimmten Datenobjekte korrekt als DTO bezeichnen, oder anders?

Das dürfte alles so passen

 

[temi]

BaseUnit dürfte ein Value-Object sein: Wenn man irgendwas ändert, ist es ja eine andere Unit.

Das klingt sinnvoll. Ich würde noch ein Feld Status (gültig, nicht gültig, o.ä.) vorsehen, da eine einmal festgelegte BaseUnit, die von einem Item verwendet wird, nicht mehr geändert werden darf.

 

[mrBrown]

Das klingt sinnvoll. Ich würde noch ein Feld Status (gültig, nicht gültig, o.ä.) vorsehen, da eine einmal festgelegte BaseUnit, die von einem Item verwendet wird, nicht mehr geändert werden darf.

Wie können denn ungültige Units entstehen?

 

[temi]

Jein, es ist eher ein Wann als ein Wo.
Stell dir ein Repo als eine Collection vor, du kannst Werte reinlegen und rausnehmen, wie bei einer Liste.
Das lebt, bevor es drin ist, das lebt, solange es drin ist, das lebt wenn du es wieder rausnimmst, das lebt, bis du es irgendwann explizit "tötest".

In meinen Worten: Der Benutzer fordert z.B. eine Liste von Items aus dem Repository an. Die Items werden aus der DB gelesen, im Repository (erzeugt und) gespeichert und dem Application-Layer zum Mapping, Anzeigen usw. weiter gegeben.

So ich merke gerade, jetzt wird es komplizierter, weil das Domänenmodell noch zu rudimentär ist:

Repositorys sollten generell keine Geschäftslogik enthalten, die gehört in Domänenobjekte und Services, sondern nur Speichern, Laden und Suchen

Der Benutzer nimmt eine Buchung für ein Item vor. Wie geht es jetzt weiter?

Ich versuche es mal selbst:
Der entsprechende Service holt sich die notwendigen Daten aus einem oder mehreren Repositories. Der Service ruft die entsprechenden Methoden auf den Domänenobjekten auf, um die Buchung vorzunehmen und speichert sie in die Repos zurück.
Es gälte jetzt noch eine Strategie festzulegen, wann die Daten wieder aus den Repos entfernt werden. Sofort wenn die Transaktion beendet wurde oder z.B. nach einer gewissen Zeit der Nichtbenutzung.

 

[temi]

Wie können denn ungültige Units entstehen?

Ungültig ist das falsche Wort, etwas besseres fällt mir gerade nicht ein. Es geht darum dass für ein erzeugtes Item mit einer bestimmten BaseUnit immer diese BaseUnit verwendet werden muss, um die Konsistenz sicher zu stellen.
Es ist aber vorstellbar, dass eine neue BaseUnit "Meter" erstellt wird, die nun eine anstatt zwei Nachkommastellen verwendet. Für neue Items ist diese dann die "gültige" BaseUnit. Der ursprüngliche zweistellige "Meter" steht für neue Items dann nicht mehr zur Verfügung.

 

[mrBrown]

In meinen Worten: Der Benutzer fordert z.B. eine Liste von Items aus dem Repository an. Die Items werden aus der DB gelesen, im Repository (erzeugt und) gespeichert und dem Application-Layer zum Mapping, Anzeigen usw. weiter gegeben.

Auf reiner Code Ebene: ja, das Repo lädt bestehende Entitäten aus der DB und gibt sie weiter.

Der Benutzer nimmt eine Buchung für ein Item vor. Wie geht es jetzt weiter?

Ich versuche es mal selbst:
Der entsprechende Service holt sich die notwendigen Daten aus einem oder mehreren Repositories. Der Service ruft die entsprechenden Methoden auf den Domänenobjekten auf, um die Buchung vorzunehmen und speichert sie in die Repos zurück.

Kommt drauf an, was eine "Buchung" ist

Aber ja, generell: die Applikation bekommt die Daten von einem Repo, ruft entsprechende Methode auf, und gibt sie in an das Repo zurück.

Es gälte jetzt noch eine Strategie festzulegen, wann die Daten wieder aus den Repos entfernt werden. Sofort wenn die Transaktion beendet wurde oder z.B. nach einer gewissen Zeit der Nichtbenutzung.

Das wäre Domänen-Logik, das Repo hat da nichts mit zu tun

Müssen Daten überhaupt gelöscht werden? Was wäre denn in Domänensprache ein löschen? Gibt es dort überhaupt ein "löschen"?

Ungültig ist das falsche Wort, etwas besseres fällt mir gerade nicht ein. Es geht darum dass für ein erzeugtes Item mit einer bestimmten BaseUnit immer diese BaseUnit verwendet werden muss, um die Konsistenz sicher zu stellen.
Es ist aber vorstellbar, dass eine neue BaseUnit "Meter" erstellt wird, die nun eine anstatt zwei Nachkommastellen verwendet. Für neue Items ist diese dann die "gültige" BaseUnit. Der ursprüngliche zweistellige "Meter" steht für neue Items dann nicht mehr zur Verfügung.

Also gibt es unterschiedliche "Typen" von BaseUnits (Meter wäre so ein Typ), und zu einem Zeitpunkt gibt es jeweils eine aktuelle Definition des Types?

 

[temi]

Also gibt es unterschiedliche "Typen" von BaseUnits (Meter wäre so ein Typ), und zu einem Zeitpunkt gibt es jeweils eine aktuelle Definition des Types?

Genau, im Regelfall gibt es eine Anzahl von BaseUnits, die nicht mehr verändert werden: ST (Stück, 0 Nachkommastellen), PK (Pack, 0 NK), M (Meter, 2 NK), usw. Falls eine dieser Einheiten verändert wird, würde ich die "alte" Einheit als "deprecated" markieren und für neue Items nicht mehr verwendbar.
Wenn ich noch einmal darüber nachdenke, dürfte die Auswahl an unterschiedlichen Basismengeneinheiten doch arg begrenzt sein, so dass es möglicherweise sinnvoll ist diese gar nicht in der DB vor zu halten, sondern fest zu hinterlegen als eine Art Set von BaseUnits.

 

[temi]

Kommt drauf an, was eine "Buchung" ist

Eine Buchung ist das Hinzufügen oder das Entnehmen von Artikeln in oder aus einem Lagerort. Artikel können an unterschiedlichen Orten oder möglicherweise mehrfach gelagert sein. Das ist in der DB durch eine Tabelle mit Fremdschlüsselbeziehungen realisiert:
fkItem, fkStorage, Amount. Im einfachsten Fall wird für eine Buchung also nur die Menge erhöht oder verringert (sofern > 0). Im gleichen Zug wird eine Prüfung durchgeführt, ob ein definierter Mindestbestand unterschritten wurde und ggf. ein Eintrag in eine entsprechende Tabelle vorgenommen. Daraus können dann sofort oder später Bestellungen generiert werden.

Was könnte also genau ablaufen:

Der User sucht nach einem bestimmten Artikel, z.B. über einen Suchbegriff

=> Aufruf Applikations-Service mit Suchbegriff
=> Aufruf Domänen-Service mit Suchbegriff
=> Aufruf Repo mit Suchbegriff
=> Rückgabe der Daten über Dom-Service an App-Service an UI-Controller
​

Der User nimmt eine Buchung (in diesem Fall eine Entnahme) vor:

=> Aufruf App-Service mit Item-Id, Lagerort-Id und Menge
=> Aufruf Dom-Service mit Item-Id, Lagerort-Id und Menge
=> Aufruf ItemStock-Repo und Prüfen des Bestands
=> Aufruf ItemStock-Repo und Ändern des Bestands
=> Ggf. Aufruf AlertRepo und Hinzufügen eines Alerts (Menge unterschritten)​

In diesem Szenario leitet der Applikations-Service Anfragen einfach an den Domänen-Service weiter. Bei der Rückgabe von Daten nimmt er zusätzlich noch ein Mapping auf UI-DTOs vor.

Wenn ich mir das so durchlese, dann steckt jetzt die gesamte Logik in den Services und die Domänenobjekte haben eigentlich gar nichts zu tun. Das kommt mir falsch vor.

 

[mrBrown]

Die Typen in der Datenbank zu halten hat durchaus auch Vorteile, zB kann man neue hinzugefügt ohne alles neu bauen zu müssen.
Das „deprecated“ kann man zB übers Datum lösen.

Wenn ich mir das so durchlese, dann steckt jetzt die gesamte Logik in den Services und die Domänenobjekte haben eigentlich gar nichts zu tun. Das kommt mir falsch vor.

Naja, ich les da überhaupt keine Geschäftslogik raus, von daher nicht verwunderlich

Das Menge erhöhen ist da mMn zu knapp erklärt, als dass man da ableiten könnte, wo und wie viel Logik da drin steckt.

Schon ein Domänen-Modell erstellt?

 

[mihe7]

die Domänenobjekte haben eigentlich gar nichts zu tun. Das kommt mir falsch vor.

Schon ein Domänen-Modell erstellt?

In dem Zusammenhang:

d.h. es sollen Artikel die in unterschiedlichen Lagern liegen

Wo ist denn z. B. das Lager modelliert?

 

[temi]

Die Typen in der Datenbank zu halten hat durchaus auch Vorteile, zB kann man neue hinzugefügt ohne alles neu bauen zu müssen.

Das war die ursprüngliche Grundidee.

Das „deprecated“ kann man zB übers Datum lösen.

Timestamp ist eine gute Idee. Die wird es sowieso geben.

Naja, ich les da überhaupt keine Geschäftslogik raus, von daher nicht verwunderlich. Das Menge erhöhen ist da mMn zu knapp erklärt, als dass man da ableiten könnte, wo und wie viel Logik da drin steckt.

Naja, sehr viel steckt auch nicht dahinter. Ich fang halt mal klein an. Für den Einstieg ist das für mich schon einigermaßen "anspruchsvoll". Mehr als prüfen, ob die Menge die entnommen werden soll auch im Lager liegt, fällt mir erst mal nicht ein.

Schon ein Domänen-Modell erstellt?

Ich habe da noch recht wenig Ahnung davon (also nur, was ich bereits darüber gelesen habe), aber ich kann es mal versuchen und zur Diskussion stellen.

Wo ist denn z. B. das Lager modelliert?

Ich hab für die Einstiegsfrage einiges weggelassen, aber die Lager an sich sind eine recht simple DB-Tabelle:

//StorageTable
UID id
String shortName // z.B. "02004"
String description // z.B. "Gebäude 2, EG, Raum 4"

Das gelagerte Material in einer weiteren Tabelle:

//ItemStockTable
UID id
UID fkItem
UID fkStorage
int amount
int limit // Mindestbestand

Frage am Rande: Der shortName der Lagerorte stellt eigentlich bereits eine Identität dar, da er eindeutig ist. Ich würde für die Datenbanktabellen trotzdem gerne einen zusätzlichen eindeutigen Schlüssel verwenden, in diesem Fall die UID, wobei die auch eine von der DB erzeugte fortlaufende Nummer sein könnte. Ist daran etwas auszusetzen?

 

[mrBrown]

die Lager an sich sind eine recht simple DB-Tabelle

Das gelagerte Material in einer weiteren Tabelle

Frage am Rande: Der shortName der Lagerorte stellt eigentlich bereits eine Identität dar, da er eindeutig ist. Ich würde für die Datenbanktabellen trotzdem gerne einen zusätzlichen eindeutigen Schlüssel verwenden, in diesem Fall die UID, wobei die auch eine von der DB erzeugte fortlaufende Nummer sein könnte. Ist daran etwas auszusetzen?

Das ist alles kein Domänen-Modell, sondern Datenbank-Details

Domänen-Modell wäre eher sowas wie "Es gibt Lager, Lager haben einen Ort und eine Beschreibung. In einem Lager ist eine bestimmte Menge an Materialien gelagert. Pro Lager gibt es dabei einen Mindestbestand eines Materials."

Das ganze halt im Idealfall noch grafisch dargestellt

 

[temi]

Domänen-Modell wäre eher sowas wie

Dann würde ich mal mit der textuellen Fassung anfangen. Ich melde mich wieder.

 

[mrBrown]

Sinnvoll ist meist eine grafische Darstellung

 

[temi]

Ungefähr so?

 

[mrBrown]

Ja, wobei beschriftete Beziehungen da super wären

Und natürlich schadet ein Blick auf die entsprechende Syntax nicht: https://de.wikipedia.org/wiki/Klassendiagramm (nicht wundern, Domänenmodell sind zwar keine Klassendiagramme, aber werden mit den gleichen Elementen modelliert)

 

[temi]

Ja, wobei beschriftete Beziehungen da super wären

Ein Beispiel wäre nett.
Gibt es dafür eine empfehlenswerte und leicht bedienbare Software, die unter Linux läuft? Mit LibreOffice ist das etwas beschwerlich.

 

[mrBrown]

Ein Beispiel wäre nett.

zB was BaseUnit mit Material zu tun hat. In dem Fall könnte es ein "wird gehandelt in Einheit"

Gibt es dafür eine empfehlenswerte und leicht bedienbare Software, die unter Linux läuft? Mit LibreOffice ist das etwas beschwerlich.

Lucidchart (wobei man das nur wirklich Sinn hat, wenn man als Student die Pro-Version gratis bekommt) oder Draw.io, sind beide Web-basiert

 

[mihe7]

Gibt es dafür eine empfehlenswerte und leicht bedienbare Software

Für schnelle, einfache Sachen nehme ich UMLet.

Ich hab für die Einstiegsfrage einiges weggelassen, aber die Lager an sich sind eine recht simple DB-Tabelle:

Das Lager kam in der Einstiegsfrage vor, wurde dann aber nicht weiter berücksichtigt. Hintergrund für das Lager war Deine Frage nach der Geschäftslogik. Die Frage wäre, ob das Lager nicht für einen Teil der Logik zuständig ist. Unabhängig davon bist Du zu sehr auf die DB fokussiert. Die interessiert erst einmal überhaupt nicht.

 

[temi]

draw.io funktioniert gut für mich. Hier ein neuer Versuch:

Unabhängig davon bist Du zu sehr auf die DB fokussiert. Die interessiert erst einmal überhaupt nicht.

Damit hast du wohl recht.

Übrigens: Ein herzliches Dankeschön an euch beiden, dass ihr euch die Zeit nehmt meine Fragen zu beantworten. Für einen Autodidakten, der das nur aus Freude am Programmieren macht, ist es nicht so leicht, wenn man keinen Ansprechpartner hat.

Wenn ich mein Werk so betrachte, dann ist es schon eher ein Klassendiagramm. Ist das so richtig? "MaterialStock" könnte anstatt der Aggregation mit "StorageLocation" auch einfach ein Feld besitzen "storageLocation: StorageLocation".

 

[horstiii1]

Für schnelle, einfache Sachen nehme ich UMLet.

Oder: http://nclass.sourceforge.net/ damit lassen sich auch schnell schöne Ergebnisse erzielen finde ich.
Normale Klassendiagramme nach UML(2.0) oder?

 

[temi]

So, ich habe noch mal etwas weiter gemacht. Hier würde ich erst mal stoppen und eure Kommentare abwarten.



Was noch fehlt: Bestellungen, Lageretiketten, ???

 

[temi]

Ich habe jetzt noch einen etwas erweiterten Ansatz versucht und dabei berücksichtigt, was ich vom Material erwarte, dass es tun kann:



Wie verfährt man im DomainModel mit Hilfsklassen wie State, StateType oder Quantity? So wie ich es jetzt gemacht habe, indem ich sie einfach als Typ angebe oder als separate Klasse mit Assoziation (wie bei State im Beitrag darüber)?

Ist das jetzt "too much" für das Material?

Alternativ könnten z.B. die Lagerplätze erst aus einem Repository geladen werden, wenn sie angefordert werden. Würde das Material dann das entsprechende Repository kennen und das selbst erledigen?

Bin ich schon wieder zu schnell, bzw. zu tief in der Implementierung?

 

[mrBrown]

Wenn ich mein Werk so betrachte, dann ist es schon eher ein Klassendiagramm. Ist das so richtig? "MaterialStock" könnte anstatt der Aggregation mit "StorageLocation" auch einfach ein Feld besitzen "storageLocation: StorageLocation".

Ja, Domänenmodelle sind rein technisch Klassendiagramm, allerdings nur mir konzeptionellen Klassen und ohne Methoden
Als Feld würde man es nur modellieren, wenn es ein primitiver Typ ist, alle anderen als Assoziationen

Wie verfährt man im DomainModel mit Hilfsklassen wie State, StateType oder Quantity? So wie ich es jetzt gemacht habe, indem ich sie einfach als Typ angebe oder als separate Klasse mit Assoziation (wie bei State im Beitrag darüber)?

Als eigene Klassen

 

[temi]

und ohne Methoden

Ok, dann nehm ich die wieder raus.

Als Feld würde man es nur modellieren, wenn es ein primitiver Typ ist, alle anderen als Assoziationen

Das wird aber evtl. recht unübersichtlich.



Ich möchte für alle Klassen einen State realisieren, d.h. ich müsste jetzt von State ausgehen Assoziationen zu allen Klassen einzeichnen. Was mache ich, z.B. mit Quantity in MaterialStock? Das wird dort für zwei Felder verwendet.

Ist das jetzt ein brauchbares DomainModel, oder fehlt etwas wichtiges?

 

[mihe7]

Die Angabe der Multiplizitäten sind auf der falschen Seite.

Das wird aber evtl. recht unübersichtlich.

Ich denke, @mrBrown meinte mit "primitive Typen" etwas anderes als int usw. Es geht mehr darum, ob es sich um ein Attribut einer Klasse (bzw. deren Objekten) handelt, oder um Beziehungen. Das Alter einer Person kann man als Attribut der Klasse Person darstellen, egal ob man "int" oder eine "Age"-Klasse verwendet.

Gibt es dagegen eine Beziehung zu einer anderen Klasse, sagen wir mal Adresse, dann stellt man so etwas gerade in der Analyse nicht mehr als Feld dar. Erstens gehen die Multiplizitäten ggf. verloren, zweitens kann man die Beziehung dann nicht vernünftig beschreiben und drittens ist die Frage, ob im Entwurf die Beziehung tatsächlich noch so umgesetzt wird.

So sehe ich die Sache zumindest

 

[mihe7]

Was mache ich, z.B. mit Quantity in MaterialStock? Das wird dort für zwei Felder verwendet.

Dann spielt eine Quantity in MaterialStock zwei verschiedene Rollen (amount, limit) und die gibt man bei der Assozitation auf Seite der Quantity an.

Nachtrag: s. z. B. https://stackoverflow.com/questions/16732607/role-name-in-association-relationship

 

[AndiE]

Ich würde an dieser Stelle mal eingreifen. Wie der TE ist es auch mir nicht so sehr gelungen, Vorlagen zur DDD zu finden. Ich habe mir deshalb das Kompakt-Buch von Vernon besorgt.

Ich würde mal den Blick auf die Fach-Seite werfen.

Momentan scheint es darauf hinauszulaufen, dass das Programm die Lagerverwaltung komplett abdecken soll. Ich würde mir dem oben angegebenen Buch vorschlagen, dass hier eine Use-Story erstellt wurde, am besten angelehnt an eine reale Einrichtung.

Beispielsweise kann ich mir eine Firma mit zwei Filialen vorstellen. An das Hauptwerk gelieferte Materialien werden intern an die Filialen versandt oder in Lager am Hauptwerk eingelagert. Wenn es eine Getränkefirma ist, ist die Anzahl der Materialien und deren Abpackung schon recht eingeschränkt. In der Regel werden aus einem Lager auch Teile entnommen, so dass immer ein Bestand vorhanden ist.

Ich würde das Modell dahingehend noch mal überprüfen.

 

[temi]

Ich habe mir deshalb das Kompakt-Buch von Vernon besorgt.

Das Buch hab ich auch - ist schon ziemlich kompakt. Irgendwie fehlt mir da noch was (vielleicht bin ich aber auch zu doof)

am besten angelehnt an eine reale Einrichtung.

Ich habe schon einen realen Hintergrund. Allerdings geht es eher um Ersatz- und Verbrauchsmaterial, das wir nicht über SAP verwalten können (dürfen). Aktuell machen wir das manuell: Fach ist leer => Katalog aufschlagen => Material bestellen. Das Problem ist häufig, dass wir Material nicht mehr finden (wir haben ein Lager im Wert von mehreren 100 T€), mit mehreren Lagerorten (z.B. Werkstatt, Keller, Dach) und vielen vielen Fächern (z.B. 001/003 => Schrank 1, Fach 3). Außerdem ist es nicht sehr praktisch, wenn man jedes mal wieder die Bestelldaten raus suchen muss und zu guter Letzt ist SAP zu doof ein Lageretikett zu drucken.

Eine User-Story ist also grob:

1. Material im System suchen (Volltext, Hersteller, Hersteller-Artikelnummer)
2. Lagerort und -platz anzeigen
3. Material entnehmen
4. Entnommene Menge aus dem Bestand ausbuchen

Sollte der Mindestbestand unterschritten werden, wird eine Bestellanforderung für diesen Artikel generiert. Die Bestellanforderung kann entweder sofort zu einer Bestellung führen oder es wird später eine "Sammelbestellung" aus aufgelaufenen Anforderungen gemacht. Die Bestellung selbst läuft über ein anderes System.

Weitere Anforderungen sind noch: Geliefertes Material in den Bestand einbuchen, Etikett für einen bestimmten Artikel oder mehrere Etiketten (z.B. Nummernbereich (Lagerort-/platzbezogen). Dazu muss zusätzlich das SAP-geführte Material aus einer CSV in dieses System importiert werden => Nummer, Kurztext, Langtext, Hersteller (nur Name), Hersteller-Artikelnummer, Lagerort, Lagerplatz, Mengeneinheit.

Vorschläge sind mir willkommen, das ist der aktuelle Stand:

 

[temi]

Wie der TE ist es auch mir nicht so sehr gelungen, Vorlagen zur DDD zu finden.

Es wäre halt klasse, DDD einmal an einem praktischen Beispiel durchzuspielen. Als "Alleinunterhalter" besteht allerdings leider das Problem, dass es kein Feedback gibt, ob man es gut macht oder alles Mist ist.

 

[AndiE]

So ist das noch nicht ideal. Vielleicht sagen dir "Lagerfachkarten" was. Im Prinzip heißt das, dass jede Entnahme zeitnah nachgewiesen wird. Diese wird dann anschließend verbucht. Sind Inhalte unter den Limit gesunken, werden dann neue zur Bestellung ausgeschrieben.

Daraus ergeben sich für mich diese Use-Cases:
1. Aufteilung: Zuerst kann man festlegen, welche Fächer es wo gibt.
2. Inventur: Nun legt man fest, wo was liegt und in welchem Umfang.
3. Zugang: Eine Lieferung von einem Lieferanten kommt. Diese wird auf die Fächer aufgeteilt
4. Entnahme: jemand schreibt eine Anforderung. Aus den entsprechenden Fächern werden die angeforderten Mengen entnommen
5. Bestand überprüfen: Der Lagerverwalter überprüft den Bestand. Ist der Bestand einer Sache unter Soll gesunken, neu bestellen.

Das würde aber einen Lagerverwalter erfordern, an den Anforderungen (Materialentnahmescheine) gestellt werden, der die Lieferungen dann entsprechend zusammenstellt.

 

[Meniskusschaden]

und zu guter Letzt ist SAP zu doof ein Lageretikett zu drucken.

Da wird wohl nicht SAP die Partei sein, die zu doof ist, ein Etikett zu drucken.

das wir nicht über SAP verwalten können (dürfen).

Vorschläge sind mir willkommen

Falls es wirklich einen guten Grund dafür geben sollte, dass die Standard-SAP-Prozesse nicht in Betracht kommen (Schwierigkeiten beim Etikettendruck würde ich nicht dazu zählen), bleibt trotzdem noch die Option, auf Basis der SAP-Entwicklungstools eine eigene Lösung zu entwickeln. Die wäre dann vernünftig im SAP-GUI integriert und den Datenaustausch per csv-könnte man sich auch sparen.

 

[temi]

Falls es wirklich einen guten Grund dafür geben sollte, dass die Standard-SAP-Prozesse nicht in Betracht kommen (Schwierigkeiten beim Etikettendruck würde ich nicht dazu zählen), bleibt trotzdem noch die Option, auf Basis der SAP-Entwicklungstools eine eigene Lösung zu entwickeln. Die wäre dann vernünftig im SAP-GUI integriert und den Datenaustausch per csv-könnte man sich auch sparen.

Vergiss es. Das wird in nächster Zeit nicht passieren. Ist aber auch egal und soll hier nicht das Thema sein. Ich möchte das Programm umsetzen, weil es ein sinnvolles Ziel ist und ich möchte es "gut" machen, weil ich "schöne" Software mag.

 

[temi]

So ist das noch nicht ideal. Vielleicht sagen dir "Lagerfachkarten" was. Im Prinzip heißt das, dass jede Entnahme zeitnah nachgewiesen wird. Diese wird dann anschließend verbucht. Sind Inhalte unter den Limit gesunken, werden dann neue zur Bestellung ausgeschrieben.

Daraus ergeben sich für mich diese Use-Cases:
1. Aufteilung: Zuerst kann man festlegen, welche Fächer es wo gibt.
2. Inventur: Nun legt man fest, wo was liegt und in welchem Umfang.
3. Zugang: Eine Lieferung von einem Lieferanten kommt. Diese wird auf die Fächer aufgeteilt
4. Entnahme: jemand schreibt eine Anforderung. Aus den entsprechenden Fächern werden die angeforderten Mengen entnommen
5. Bestand überprüfen: Der Lagerverwalter überprüft den Bestand. Ist der Bestand einer Sache unter Soll gesunken, neu bestellen.

Das würde aber einen Lagerverwalter erfordern, an den Anforderungen (Materialentnahmescheine) gestellt werden, der die Lieferungen dann entsprechend zusammenstellt.

Ehrlich gesagt, weiß ich nicht genau was du mir sagen möchtest. Soll ich einen Karteikasten kaufen?

 

[temi]

So ist das noch nicht ideal.

Kannst du das bitte begründen. Was ist nicht ideal und warum?

 

[AndiE]

Vielleicht habe ich auch einen Denkfehler. Ich würde mal einen "Schreibtischtest" durchführen.
"Transport Timm liefert 10 Büchsen Farbe von "Bunt& Klar", 5 Rollen Kabel von "Elektro-Meier" und 5 Kisten Schrauben von "Schrauben-Paul". Diese Dinge werden in die Lagerfächer 1 bis 3 einsortiert. Am Ende des Tages sind 2 Büchsen Farbe entnommen, 1 Rolle Kabel und 1 Kiste Schrauben. Nach einer Woche sind nur noch 2 Dosen Farbe da- Sie muss nachbestellt werden."

Kann das Modell diese Vorgänge abbilden? Momentan ist es auch nicht sichtbar, wer was entnimmt, glaube ich. Ist das nicht wichtig? Soweit ich das sehe, kann die wichtige Frage: "Was haben wir noch an Material X an den 3 Standorten" nochjt geklärt werden.

Sorry, wenn ich falsch liege, aber das ist mein Eindruck.

 

[mihe7]

Soweit ich das sehe, kann die wichtige Frage: "Was haben wir noch an Material X an den 3 Standorten" nochjt geklärt werden.

Zwischen StorageLocation und MaterialStock dürfte eine 1:n-Beziehung bestehen (die wäre im Diagramm falsch). Zwischen MaterialStock und Material eine n:1-Beziehung.

In SQL: SELECT location_id, material_id, sum(amount) FROM material_stock GROUP BY location_id, material_id;

 

[mrBrown]

Ich denke, @mrBrown meinte mit "primitive Typen" etwas anderes als int usw. Es geht mehr darum, ob es sich um ein Attribut einer Klasse (bzw. deren Objekten) handelt, oder um Beziehungen. Das Alter einer Person kann man als Attribut der Klasse Person darstellen, egal ob man "int" oder eine "Age"-Klasse verwendet.

Gibt es dagegen eine Beziehung zu einer anderen Klasse, sagen wir mal Adresse, dann stellt man so etwas gerade in der Analyse nicht mehr als Feld dar. Erstens gehen die Multiplizitäten ggf. verloren, zweitens kann man die Beziehung dann nicht vernünftig beschreiben und drittens ist die Frage, ob im Entwurf die Beziehung tatsächlich noch so umgesetzt wird.

So sehe ich die Sache zumindest

Ja, so meinte ich das

 

[temi]

Zwischen StorageLocation und MaterialStock dürfte eine 1:n-Beziehung bestehen

Das ist nicht richtig. Bei MaterialStock handelt es sich um die lagerplatzbezogene Menge, d.h. 1:1.

Kann das Modell diese Vorgänge abbilden?

Ich denke doch: Beim Einbuchen des Materials ist es nicht relevant, wer liefert oder von wem geliefert wurde. Das Material mit einer bestimmten Materialnummer wird in den (die) vorgesehenen Lagerorte/-plätze eingelagert und eingebucht. Entnahmen erfolgen analog. Wer das Material entnimmt oder einlagert ist nicht relevant, könnte aber in der PostTransaction erfasst werden, falls erforderlich.

Soweit ich das sehe, kann die wichtige Frage: "Was haben wir noch an Material X an den 3 Standorten" nochjt geklärt werden.

Standorte wären z.B. Werke. Das ist nicht vorgesehen und nicht erforderlich. Ich nehme an du meinst Lagerorte. Insofern bei einer Entnahme korrekt gebucht wurde, ist das abgedeckt.

 

[temi]

Ja, so meinte ich das

Dann wäre das Modell ja in der Beziehung richtig, richtig?

 

[mrBrown]

Das ist nicht richtig. Bei MaterialStock handelt es sich um die lagerplatzbezogene Menge, d.h. 1:1.

Ja, aber in einem Lager kann es mehrere MaterialStocks geben, oder nicht?

PostTransaction

Was soll dies denn sein?

 

[temi]

Ja, aber in einem Lager kann es mehrere MaterialStocks geben, oder nicht?

Ist das nicht durch die angegebene Multiplizität ausgedrückt?

Was soll dies denn sein?

Laut LEO wäre "posting" eine mögliche Übersetzung für Warenbewegung. Ich nehme auch gerne eine bessere Bezeichnung. Movement? MoveTransaction?

 

[mihe7]

Ist das nicht durch die angegebene Multiplizität ausgedrückt?

Nö. Zu einem MaterialStock gibt es einen Lagerplatz -> die 1 gehört auf die Seite von StorageLocation. Zu einem Lagerplatz gibt es mehrere MaterialStocks: auf Seite von MaterialStock müsste dann * (bzw. 0..*) stehen.

 

[temi]

die 1 gehört auf die Seite von StorageLocation

Ist sie schon... (#48 - die hatte ich übersehen)

Zu einem Lagerplatz gibt es mehrere MaterialStocks

Ich denke eher: Zu einem Material gibt es mehrere MaterialStocks und das steht doch auch da.
Oder verstehe ich hier generell etwas falsch?

Edit: Vielleicht gibt es ja für euch auch einen guten Grund, das von der anderen Seite zu sehen. Für mich ist das Material der zentrale Punkt.