AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Architektur/Design Patterns eines ERP/CRM Systems

Architektur/Design Patterns eines ERP/CRM Systems

Ein Thema von michele_tedesco · begonnen am 10. Apr 2014 · letzter Beitrag vom 30. Apr 2014
Antwort Antwort
Seite 1 von 2  1 2   
michele_tedesco

Registriert seit: 19. Mär 2014
50 Beiträge
 
#1

Architektur/Design Patterns eines ERP/CRM Systems

  Alt 10. Apr 2014, 14:21
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?

Geändert von michele_tedesco (10. Apr 2014 um 14:41 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.753 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: Architektur/Design Patterns eines ERP/CRM Systems

  Alt 10. Apr 2014, 15:42
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
Oliver
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#3

AW: Architektur/Design Patterns eines ERP/CRM Systems

  Alt 10. Apr 2014, 16:19
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.

Geändert von Namenloser (10. Apr 2014 um 16:27 Uhr)
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#4

AW: Architektur/Design Patterns eines ERP/CRM Systems

  Alt 11. Apr 2014, 08:38
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.
  Mit Zitat antworten Zitat
vagtler

Registriert seit: 9. Jul 2010
Ort: Köln
667 Beiträge
 
Delphi 2010 Professional
 
#5

AW: Architektur/Design Patterns eines ERP/CRM Systems

  Alt 11. Apr 2014, 10:30
[...] Javaumfeld.
Wo war denn die Rede von Java?
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
3.003 Beiträge
 
Delphi 2009 Professional
 
#6

AW: Architektur/Design Patterns eines ERP/CRM Systems

  Alt 11. Apr 2014, 10:42
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")
Michael Justin
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#7

AW: Architektur/Design Patterns eines ERP/CRM Systems

  Alt 11. Apr 2014, 10:46
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
3.003 Beiträge
 
Delphi 2009 Professional
 
#8

AW: Architektur/Design Patterns eines ERP/CRM Systems

  Alt 11. Apr 2014, 10:56
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/
Michael Justin

Geändert von mjustin (11. Apr 2014 um 11:06 Uhr)
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#9

AW: Architektur/Design Patterns eines ERP/CRM Systems

  Alt 11. Apr 2014, 14:54
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 #
  Mit Zitat antworten Zitat
mquadrat

Registriert seit: 13. Feb 2004
1.113 Beiträge
 
Delphi XE2 Professional
 
#10

AW: Architektur/Design Patterns eines ERP/CRM Systems

  Alt 14. Apr 2014, 09:13
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
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:59 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz