Die Entwickler müssen genau hinhören, was mit manchen Begriffen gemeint ist. (Quelle: Fotolia)
Im vorherigen Artikel habe ich erläutert, wie der Domänenbegriff Kunde in unterschiedlichen Bedeutungen verwendet wird. In diesem Post mache ich einige Vorschläge, welche zeigen, wie es sich besser machen lässt.
Der Kunde im Verkauf ist die Person, die meine Produkte kauft. Er ist also der Käufer.
Im Support ist der Kunde derjenige, der meine Produkte bedient und sich bei Fragen zur Bedienung an den Support wendet. Da könnten vielleicht Anwender oder Nutzer als Begriffe in Frage kommen.
Im Rechnungswesen ist der Kunde derjenige, der mir Geld für meine Produkte schuldet und die Schuld dann hoffentlich begleicht. Schuld => Debit => Debitor. Oder alternativ Kontoinhaber. Das wiederum könnte aber zur Verwechslung mit den Lieferanten führen, die natürlich auch Kontoinhaber sind. Also nehmen wir besser Debitor.
Im Versand oder im Lager geht es darum die Produkte an einen Empfänger auszuliefern. Wir benötigen die Adresse, um das Paket, das die Ware erhält, zu adressieren. Also Empfänger, Adressat, Warenempfänger – man hat die freie Auswahl.
Das Marketing hat unter anderem die Ziele, die Neukundenakquise mit Werbemaßnahmen anzukurbeln, gleichzeitig aber die Kundenbindung zu festigen. Also wie wäre es mit Neukunde und Bestandskunde. Alternativ potentieller Kunde oder – für manche Branchen denkbar – Kandidat.
Fazit
Es muss nicht immer schwer sein gute Domänenbegriffe zu finden, die klar ausdrücken, worum es sich bei dem Konzept handelt. Oftmals genügt es sich die Domäne, in der der Begriff verwendet wird, anzuschauen und zu umschreiben, was der Begriff ausdrücken soll. Mit der Erfahrung wird das für den Fachexperten ganz selbstverständlich und ihm springen förmlich schlechte Benennungen ins Gesicht (schon mal über das Konzept der ‚Benutzer‘ nachgedacht?).
In meinem nächsten Artikel kommen wir zu der spannenden Frage, woher die technischen Probleme bei Vermengungen von Bedeutungen kommen.
Mit Tag(s) versehen: DDD
Uli Armbruster 
[…] nächsten Teil erläutere ich Beispiele, die zeigen: Hey, das ist gar nicht so schwer eine klare Unterscheidung zu […]
LikeLike
[…] ich im vorherigen Beitrag Beispiele zur Abgrenzung des fachlichen Konzepts Kunde gegeben habe, möchte ich in dem […]
LikeLike
Interessanter Ansatz den du da hast. Mir ist gleich das Wort “Rolle“ in den Sinn gekommen, denn alle unterschiedlichen Betrachtungsweisen drücken Kunden, aber auch alle anderen Teilnehmer in passende Rollen. Oder sehe ich das falsch?
LikeLike
Hey Andre,
Rolle würde in dem vorliegenden Szenario passen, drückt das aber aus meiner Sicht nicht allgemein genug aus. Mir ging es darum zu zeigen, dass man seine Modelle/Domänen kleiner schneiden sollte, wenn dies möglich und sinnvoll ist. Stichwort Domain Driven Design. Ich kann dir noch ein Beispiel nennen, bei dem man dann nicht von Rollen sprechen kann: Lagerartikel. Lagerartikel sind fürs Lager alle Artikel, die physikalisch auch tatsächlich „im Haus“ sind. Für den Einkäufer sind Lagerartikel nur die, für die der Einkauf verantwortlich ist und die er alleine auf Lager legen darf. Für den Verkäufer sind vielleicht auch noch Artikel eines Konsignationslagers, also ein Lager bei unserem Kunden vor Ort, enthalten. Obwohl alles Lagerartikel heißt, sind es völlig unterschiedliche Konzepte.
LikeLike
So habe ich das Ganze noch nie betrachtet. Danke für den Impuls!
LikeGefällt 1 Person
Gerne
LikeLike