GEBIT Solutions - Die Experten für IT im Handel

Glossar

In diesem Bereich werden einige der häufig verwendeten Begriffe im Zusammenhang mit der GEBIT Retail Platform definiert und erklärt.

 

 


Bounded Context


Kontextgrenzen beschreiben allgemein die Grenzen eines Kontextes wie beispielsweise fachlicher Bereich, Verwendungszweck, Team, etc.

Weiterführende Links zur Verwendung im Domain-Driven-Design:

Martin Fowler: https://www.martinfowler.com/bliki/BoundedContext.html

 


Business Component (BC)


Eine Business Component (BC; Geschäftskomponente) ist ein abgeschlossenes, eigenständig lauffähiges Softwaresystem. Technisch betrachtet ist eine BC oftmals (aber nicht zwingend) deckungsgleich mit einem Microservice. Fachlich bzw. vom Design der Anwendungslandschaft her betrachtet ist eine BC oftmals das gleiche wie ein Bounded Context im Domain-Driven-Design.

 


Business Component Identifier (BCI)


Ist der eindeutige Name einer Business-Component in einem RPD, unabhängig von existierenden Instanzen dieser.

Beispiele: "Customer", "EmployeeApp", etc.

Im Domain-Driven-Design ist dies also der Name eines Bounded Context.

 

 


Click & Collect


Ein Omnichannel Anwendungsfall, bei dem der Kunde online (in einer App oder einem Webshop) Artikel bestellt und auch bereits online bezahlt, aber diese in einem ausgewählten Markt selbst abholt.

 


Click & Reserve


Ein Omnichannel Anwendungsfall, bei dem der Kunde online (in einer App oder einem Webshop) Artikel in einem Markt reserviert (zurücklegen lässt) und diese dann später dort begutachtet und ggf. natürlich auch kauft.

 


Domain-Driven-Design (DDD)


Die GEBIT Retail Platform wird nach den Prinzipien des Domain-Driven-Design entwickelt.

Domain-driven Design (DDD) ist eine Herangehensweise an die Modellierung komplexer Software. Die Modellierung der Software wird dabei maßgeblich von den umzusetzenden Fachlichkeiten der Anwendungsdomäne beeinflusst. Der Begriff „Domain-driven Design“ wurde 2003 von Eric Evans in seinem gleichnamigen Buch geprägt.

Domain-driven Design ist nicht nur eine Technik oder Methode. Es ist vielmehr eine Denkweise und Priorisierung zur Steigerung der Produktivität von Softwareprojekten im Umfeld komplexer fachlicher Zusammenhänge. Domain-driven Design basiert auf folgenden zwei Annahmen:

  • Der Schwerpunkt des Softwaredesigns liegt auf der Fachlichkeit und der Fachlogik.
  • Der Entwurf komplexer fachlicher Zusammenhänge sollte auf einem Modell der Anwendungsdomäne, dem Domänenmodell basieren.

Domain-driven Design ist an keinen bestimmten Softwareentwicklungsprozess gebunden, orientiert sich aber an agiler Softwareentwicklung. Insbesondere setzt es iterative Softwareentwicklung und eine enge Zusammenarbeit zwischen Entwicklern und Fachexperten voraus.

Quelle: Wikipedia, abgerufen am 29.10.2019

 


Kommunikationsbausteine


Die elementaren Kommunikationsbausteine der GEBIT Retail Platform sind:

- Commands: ein Command ist die Aufforderung an eine Komponente, einen Dienst zu erbringen bzw. allgemein, etwas bestimmtes zu tun. In welcher Weise die angesprochene Komponente dieser Aufforderung nachkommt, entscheidet diese selbst anhand der ihr vorliegenden Informationen und definierten Geschäftsregeln. Beispiele: "Kunde anlegen", "Einkaufsposition dem Warenkorb hinzufügen", "Kreditkartenzahlung durchführen", etc.

- Events: ein Event ist eine Benachrichtigung über ein Ereignis, das innerhalb der Retail Platform stattgefunden hat. Beispiele: "Kunde wurde angelegt", "Kartenzahlung wurde durchgeführt", "Kunde hat in den Markt eingecheckt", etc.

Oftmals hat ein einzelnes Command einen oder auch mehrere Events zur Folge. Die Events beschreiben dann u.a. das Ergebnis des Commands, also ob und in welcher Weise es ausgeführt wurde und - im Falle mehrerer Events - ob es weitere Ereignisse ausgelöst hat. Ereignisse können aber auch ohne zugehörige (explizite) Commands auftreten, z.B. kann der Ablauf einer Frist bezogen auf einen Geschäftsprozess ein Ereignis auslösen.

Verantwortlich für den sicheren Transport und die garantierte Zustellung von Commands und Events an die Komponenten ist der Event-Bus.

 


Microservice


Microservices sind ein Architekturmuster der Informationstechnik, bei dem komplexe Anwendungssoftware aus unabhängigen Prozessen komponiert wird, die untereinander mit sprachunabhängigen Programmierschnittstellen kommunizieren. Die Dienste sind weitgehend entkoppelt und erledigen eine kleine Aufgabe. So ermöglichen sie einen modularen Aufbau von Anwendungssoftware.

Quelle: Wikipedia, abgerufen am 29.10.2019

 


Retail Business Location (RBL)


Beschreibt einen Ort, an dem Geschäftsoperationen stattfinden und Ereignisse ausgelöst werden können.

An jeder Lokation können sich eine oder mehrere Systeme, Anwendungen und Komponenten und optional Akteure befinden, die mit diesen interagieren.

Der allgemeine Aufbau ist: <LocationKind>.<LocationDefinition>

Die standardmäßig definierten Möglichkeiten sind:

  1. Store.<StoreLocation>
    Ladengeschäfte
  2. Central.<CentralLocation>
    Zentrale oder auch regionale Firmenlokationen
  3. Mobile.<MobileLocation>
    Mobile Lokationen, i.w. also personengebundene Apps

Der konkrete Aufbau der jeweiligen Location-Definitionen ist RPD-abhängig.

Beispiele für den möglichen Aufbau von Store-Locations in konkreten RPDs (nur eine Form kommt in einer konkreten RPD zur Anwendung):

  1. <StoreNumber>
    z.B. "Store.4321"
  2. <Country>.<StoreNumber>
    z.B. "Store.DE.1234"
  3. <Country>.<Company>.<StoreNumber>
    z.B. "Store.DE.MadMen.4711"
  4. <Company>.<Country>.<StoreName>
    z.B. "Store.MadMen.DE.4711"
  5. <Country>.<Region>.<StoreNumber>
    z.B. "Store.DE.NRW.17"
  6. <Country>.<StoreType>.<StoreNumber>
    z.B. "Store.CH.Popup.3", "Store.US.Flagship.2"

Beispiele für den möglichen Aufbau von Central-Locations in konkreten RPDs (nur eine Form kommt in einer konkreten RPD zur Anwendung):

  1. <CentralName>
    z.B. "Central.HQ", "Central.MadShop"
  2. <Country>
    z.B. "Central.DE"
  3. <Country>.<CentralNumber>
    z.B. "Central.DE.3"

Beispiele für den möglichen Aufbau von Mobile-Locations in konkreten RPDs (nur eine Form kommt in einer konkreten RPD zur Anwendung):

  1. <AppName>.<UserId>
    z.B. "Mobile.PowerShopper.4399942334"
  2. <UserKind>.<UserId>
    z.B. "Mobile.Customer.4399942334"
  3. <UserId>
    z.B."Mobile.8458534552"

 


Retail Platform Deployment (RPD)


Eine konkrete Realisierung der GEBIT Retail Platform mit konkreten Komponenten in der Organisation eines Händlers. Dies umfasst:

  • eine konkrete Menge von Anwendungen und Komponenten sowie eindeutige Namen für jede dieser Komponenten.
  • eine konkrete Menge von Lokationen, an denen diese installiert sind sowie ein konkretes Schema, mit dem diese Lokationen beschrieben werden.

 


Ship to Home


Eine Versandoption, bei der gekaufte Ware zum Kunden nach Hause geliefert wird.

Bei Online-Einkäufen ist dies der Standard und es bilden dort die Anwendungsfälle Click & Collect oder Click & Reserve die Besonderheit bzw. Ausnahme.

Bei stationären Einkäufen in einem Markt ist der Standard eine unmittelbare Mitnahme der gekauften Waren durch den Kunden. Hier ist dann Ship to Home die Besonderheit bzw. Ausnahme, wobei sich dies auf Waren beziehen kann, die bereits im Markt vorrätig sind oder auch auf Online-Bestellungen, die aus dem Markt heraus getätigt werden.