Architektur/Design Patterns eines ERP/CRM Systems

[michele_tedesco]

Um die Zeitmessung des Berlins Marathon (dient als Beispiel, um ein Kontext zu haben) zu organisieren benötigt es:
- Ein E-COMMERCE System, wo die Läufer die "Tickets" (also eine Startnummer) für diesen Event kaufen können.
- Ein ZEITMESS-SYSTEM, wo vor Ort an verschiedenen Strecken-Abschnitte und am Schluss die Zeit der Läufer misst.
- Ein SOCIAL-PORTAL, wo die Resultate der Athleten über die Jahre ersichtlich sind und wo sich Läufer austauschen können
- Ein CRM, wo die Läufer verwaltet werden

Dies ist ein sehr high-level use case, um ein Marathon aus Software-Sicht zu unterstützen.

Wie würdet ihr die Architektur von einem solchen System, oder der verschiedene vernetzten System designen?

Mein Vorschlag:
- Eine Social-Plattform, welche nach dem MVVM Pattern aufgebaut ist, ein HTML5/JS UI hat, das über Websocket mit einem event-driven async Applikation-Backend Server verbindet.
- In der Social-Plattform soll auch ein eingeschränktes E-Commerce System vorhanden sein.
- Für das CRM auch eine MVVM Applikation mit HTML/JS im UI und RESTful Verbindungen zu einem "CRUD"-Backend-Server (aufgebrochen in einem Service-Layer, einem Business-Logic-Layer, einem Data-Access-Layer und einer DB)
- Für das Zeitmess-System werden alle Sensoren über TCP direkt im LAN oder über ein Internet-Proxy (über ein UMTS/LTE-Modem) an einem Node.JS Server angebunden, welches die async verarbeitet und auch über ein HTML/JS UI diese Daten bearbeitet werden können.
- Die verschiedene Systeme kommunizieren über eine Message-Queue untereinander und tauschen somit Daten async aus


Was haltet ihr davon?
Wo liege ich technologisch, oder sonst absolut falsch mit meiner theoretischen Umsetzung?

[Sherlock]

Tut mir Leid, da sind dermaßen viele "Buzzwords und Akronyme" drin...Du hast mich alten Knochen gnadenlos abgehängt. :(

Ich hätte alles mit einer DB und einem einigermaßen hübschen Web-Frontend gelöst, aber vermutlich lässt sich das durch Deine "Buzzwords und Akronyme" einfacher zusammenfassen, ich verstehe es nur nicht.

Sherlock

[Namenloser]

Was wird auf der „Social Platform“ angezeigt und wie? Wie werden Zeiten gemessen und wann?

Aktuell stell ich mir das aus deiner Beschreibung so vor, dass es auf der „Social Platform“ so eine Art Facebook-Timeline gibt, und immer wenn jemand einen Streckenabschnitt geschafft hat, wird das in Echtzeit als neues Event dort angezeigt. So ähnlich wie hier, bloß nicht mit Bitcoins. Liege ich da richtig?

Dann ist noch die Frage, welche Geräte sollen unterstützt werden? Desktops/Smartphones/Tablets? Heutzutage vermutlich alles. Dann ist noch die Frage, wie diese Unterstützung umgesetzt wird. Als einziges Design, das sich per CSS3 dynamisch anpasst, oder verschiedene, spezialisierte Seiten? Gibt es vielleicht auch noch andere Frontends, z.B. eine App?

Wo kommt es überhaupt zur Kommunikation zwischen den drei Teilsystemen „CRM“, „E-Commerce“ und „Social Platform“?

Was bedeutet bei dir „asynchron”? Heißt es nur nicht-blockierend, oder heißt es auch, dass auch die zeitliche Reihenfolge nicht sicher ist? Was wären die Probleme, die eventuell daraus resultieren könnten?

Wie häufig entstehen neue Events? Könnte es passieren, dass sie nicht mehr schnell genug abgearbeitet werden können? Können Events verloren gehen, weil beispielsweise die UMTS-Verbindung versagt? Was wären die Konsequenzen?

Gibt es einen bestimmten Grund für Node.JS, außer dass es gerade hip ist?


Das wären so die Fragen, die ich mir stellen würde. Ich habe so ein System aber auch noch nie designt, daher kann ich dir wohl auch keine konkreten Ratschläge geben. Ich weiß bloß, dass es für Echtzeit-Updates auch Dienstleister wie z.B. diesen gibt (den verwendet Humble Bundle). Wo da genau die Vorteile liegen, weiß ich nicht, aber sollte man sich vielleicht auch mal anschauen.

[Dejan Vu]

Klingt alles ganz passabel, aber auch naheliegend. Aber ich würde beim Hausbau nicht mit dem Dach beginnen.

Du schreibst von E-Commerce, Social Platform, Zeitmess-System und CRM. Ich würde anfangen, diese System erst einmal zu konzipieren, und zwar ohne ein einziges Buzzword zu verwenden. Und ohne UI, denn die ist nur Beiwerk für die Entitäten, die dafür sorgen, das man sich ärgert (die so.g. 'User') ;-)

Nach dem Grobkonzept (Usecases) geht es an die zu verwendenden Softwaretechniken, damit deine Unittests möglichst umfassend werden und alles abdecken, dabei aber mengenmäßig nicht ausufern. Denke dabei an die drei Säulen der Peinlichkeitsvermeidung: DRY, KISS und YAGNI.

Wenn Du dann ein deine durch Unittests abgedeckten Systeme hast, kannst Du dir überlegen, wie das ganze verknüpfst und eine (oder mehrere) UI oben rauf pflanzen.

So wie ich das sehe, scheinst Du nicht genau zu wissen, was Du eigentlich willst und schiebst deswegen Buzzwords vor dir her, damit man nicht merkt, das Du eigentlich nicht allzuviel Ahnung von der Materie hast. Wie übrigens so ziemlich alle hier im Forum. Mich eingeschlossen, denn ich bewege mich nicht im Web/Javaumfeld.

[vagtler]

Zitat:

Zitat von Dejan Vu (Beitrag 1255274)

[...] Javaumfeld.

Wo war denn die Rede von Java?

[mjustin]

Zitat:

Zitat von vagtler (Beitrag 1255303)

Wo war denn die Rede von Java?

Indirekt schon im ersten Beitrag:

Zitat:

- Für das Zeitmess-System werden alle Sensoren über TCP direkt im LAN oder über ein Internet-Proxy (über ein UMTS/LTE-Modem) an einem Node.JS Server angebunden

Das 'js' in 'Node.js' steht für 'JavaScript' ;) (... ja, ich weiss: "Javascript" <> "Java")

[Sir Rufo]

Zitat:

Zitat von mjustin (Beitrag 1255308)

Zitat:

Zitat von vagtler (Beitrag 1255303)

Wo war denn die Rede von Java?

Indirekt schon im ersten Beitrag:

Zitat:

- Für das Zeitmess-System werden alle Sensoren über TCP direkt im LAN oder über ein Internet-Proxy (über ein UMTS/LTE-Modem) an einem Node.JS Server angebunden

Das 'js' in 'Node.js' steht für 'JavaScript' ;) (... ja, ich weiss: "Javascript" <> "Java")

Er sprach auch nicht von Java sondern Javaumfeld und da gehört JavaScript nun mal rein.

[mjustin]

Zitat:

Zitat von Namenloser (Beitrag 1255209)

Gibt es einen bestimmten Grund für Node.JS, außer dass es gerade hip ist?

Node.JS ist besonders geeignet für Anwendungen die eine grosse Zahl gleichzeitiger Verbindungen ressourcenschonend erlauben. Natürlich kann man auch andere Server einsetzen - man braucht dann aber eventuell eine signifikant größere Serverfarm, wenn gleichzeitig zehntausende Benutzer Webseiten besuchen, die mit Ajax oder Websocket arbeiten.

Aber es muss nicht Node.JS sein. Java Application Server unterstützen seit einiger Zeit auch Websocket und asynchrone Requestverarbeitung (Servlet 3.0 API) mit deutlich geringerem Resourcenverbrauch.

Vergleichstests einiger Serverframeworks: http://www.techempower.com/benchmarks/

[Dejan Vu]

Nee nee, das ist für mich nun mal eine Soße, weil ich mich in dem Feld nicht bewege. So wie eben Javaskriptentwickler den Unterschied zwischen C-ohne-kreuze und C-mit-Kreuzen nicht kennen. Es soll sogar Leute geben, für die ist C++ = C#, denn wenn man zwei Plus-Zeichen leicht versetzt übereinander packt, sieht das ja aus wie ein # :wall:

[mquadrat]

Zitat:

Zitat von datasportdev (Beitrag 1255194)

Mein Vorschlag:
- Eine Social-Plattform, welche nach dem MVVM Pattern aufgebaut ist, ein HTML5/JS UI hat, das über Websocket mit einem event-driven async Applikation-Backend Server verbindet.
- In der Social-Plattform soll auch ein eingeschränktes E-Commerce System vorhanden sein.
- Für das CRM auch eine MVVM Applikation mit HTML/JS im UI und RESTful Verbindungen zu einem "CRUD"-Backend-Server (aufgebrochen in einem Service-Layer, einem Business-Logic-Layer, einem Data-Access-Layer und einer DB)
- Für das Zeitmess-System werden alle Sensoren über TCP direkt im LAN oder über ein Internet-Proxy (über ein UMTS/LTE-Modem) an einem Node.JS Server angebunden, welches die async verarbeitet und auch über ein HTML/JS UI diese Daten bearbeitet werden können.
- Die verschiedene Systeme kommunizieren über eine Message-Queue untereinander und tauschen somit Daten async aus

Möchtest du mit dem Websocket das Long-Polling umgehen? Für meinen Geschmack sind es - wenn es schon als Gesamtanwendung konzipiert ist - zu viele unterschiedliche Vorgehensweisen und Technologien.

Bei der Zeitmessung: Von wievielen Sensoren reden wir hier denn? Hier würde sich ja auch ein ganz klassischer eigener TCP-Server mit persistenten Verbindungen anbieten. Spart den Verbindungsaufbau und du merkst auf der Server-Seite sofort, wenn dir der Port zugeht weil ein Besucher übers Kabel gefallen ist :D

[vagtler]

Zitat:

Zitat von Dejan Vu (Beitrag 1255346)

Nee nee, das ist für mich nun mal eine Soße, weil ich mich in dem Feld nicht bewege. [...]

Java aufs Webumfeld zu reduzieren halte ich für sehr gewagt. Selbst JavaScript ist nicht mehr ausschließlich dort zuhause.

Zitat:

[...]*So wie eben Javaskriptentwickler den Unterschied zwischen C-ohne-kreuze und C-mit-Kreuzen nicht kennen. [...]

Das ist eine sehr gewagte Verallgemeinerung.

Schubladendenken?

[Dejan Vu]

Zitat:

Zitat von vagtler (Beitrag 1255540)

Das ist eine sehr gewagte Verallgemeinerung.
Schubladendenken?

Erfahrung gewürzt mit Polemik. Leg mal nicht immer jede Bemerkung auf die Goldwaage. So ernst ist das Leben ja nicht.

[vagtler]

Zitat:

Zitat von Dejan Vu (Beitrag 1255568)

Erfahrung gewürzt mit Polemik. [...]

:thumb:

[Sherlock]

Hier mal was aus meiner Schublade: Das Thema ist durch...da kommt null Feedback vom OP.

Angesichts des Bingo-Spiels am Anfang vorhersehbar... :evil:

Sherlock

[mjustin]

Zitat:

Zitat von mquadrat (Beitrag 1255535)

Hier würde sich ja auch ein ganz klassischer eigener TCP-Server mit persistenten Verbindungen anbieten.

Persistente Verbindungen führt dann aber zu höherem Resourcenverbrauch auf dem Server, wenn man "klassisch" mit einem Thread je Verbindung arbeitet. Mit Indy zum Beispiel wird es nicht leicht, wenn zehntausende Clients gleichzeitig versorgt werden wollen, selbst wenn diese nur "gelegentlich" Daten senden.

Die Verbindungen ad-hoc (wenn es etwas zu senden gbt) neu aufzubauen und danach sofort wieder zu trennen ist auch keine Lösung. Der Server hat dann nach einiger Zeit keine verfügbaren TCP Ports mehr (getrennte Verbindungen stehen für einige Zeit noch auf TIME_WAIT).

Vor die Wahl gestellt, sind dann persistente Verbindungen kombiniert mit einem asynchron arbeitenden Server und Workerthreads resourcenschonender (auch für Delphi gibt es asynchron arbeitende TCP Server, es muss nicht Node.JS sein).

[Mavarik]

Zitat:

Zitat von Sherlock (Beitrag 1255205)

Tut mir Leid, da sind dermaßen viele "Buzzwords und Akronyme" drin...Du hast mich alten Knochen gnadenlos abgehängt. :(

Ich hätte alles mit einer DB und einem einigermaßen hübschen Web-Frontend gelöst, aber vermutlich lässt sich das durch Deine "Buzzwords und Akronyme" einfacher zusammenfassen, ich verstehe es nur nicht.

Sherlock

[OT]

LOL genau...

Warum erinnert mich das an dieses Video?

Mavarik

[/OT]

[Sherlock]

Zitat:

Zitat von Mavarik (Beitrag 1255643)

Warum erinnert mich das an dieses Video?

Ich denke, Dir geht es da wie mir und alles erinnert dich derzeit an das Video :lol:

Sherlock

[Dejan Vu]

Zitat:

Zitat von Sherlock (Beitrag 1255667)

Zitat:

Zitat von Mavarik (Beitrag 1255643)

Warum erinnert mich das an dieses Video?

Ich denke, Dir geht es da wie mir und alles erinnert dich derzeit an das Video :lol:

:thumb: Made my day. :lol:

[michele_tedesco]

Danke für den Video-Link :-)

Zusammengefasst nehme ich mit, dass zu viele Konzepte, oder Probleme auf einmal bearbeitet werden.

Ich werde mein Vorgang ändern und zuerst die "Probleme" mit dem Business priorisieren.
Anschliessend wird sich zeigen, welche Funktionalität (und mit welcher Technologie) programmiert werden muss.

Danke für all die Feedbacks anyway :-)