vision

Stimulating and validating services is so easy with the surround studio suite.

Das Konzept

 

Clean Architecture

 Das Surround Framework kümmert sich um das “Drumherum”, eben den Surround, zwischen den einzelnen Technologien. Es besteht aus dem Modellierungskern – SurroundModel –  und und den drei Grund APIs:

Show – Surround DynamicUI
Save – Surround Data
Send – Surround Messaging

Es folgt dem Clean Architecture Ansatz von Robert C.Martin. Dabei ist der Abhängigkeitsgraph umgedreht. Die Application ruft nicht direkt eine Technologie auf, sondern nur die eigene schlanke API. Für jede Technologie wird ein spezieller Adapter implementiert – z.B. DataByElasticsearch oder MessagingByAkka – als eigenes Modul. Dieser wird dann unter der Haube – als plugin – eingebunden ohne das die Application dies unmittelbar sieht. 

 

Diese leichtgewichtige Anbindung wird es ermöglichen, daß sich Technologien leicht austauschen lassen. Denn der aplikative code enthält keinerlei „Technologie Verschmutzung“. Es entsteht nur Arbeit für das Surround Team, um die neue Technologie anzubinden, die anderen Entwickler können ungestört weiter arbeiten – siehe auch Dynamic OOAD

Das ist der Traum jedes Architekten, der aufgrund der “Explosion der möglichen Tools” unter enormen Entscheidungsdruck steht.Denn wenn man Technologien gefahrlos austauschen kann, so kann man auch den “Letzten Vernüftigen Moment” einer Technikentscheidung so weit wie möglich herauszögern und so mehr über die Lösungsalternativen lernen und vieleicht auch mehrere Kandiaten weiter verfolgen.

Das gilt auch für das Surround Studio selbst. So haben wir uns ein paar bewährte aber auch “hippe” Frameworks ausgesucht aus dem “Zoo der Technologien”.

 

Model Driven

Surround ist modell getrieben. Das SurroundModel bietet ein erweiterbares Typ-System für die BottomUp Modellierung. Damit lassen sich Domain Modelle,  aber auch Kommunikations Modelle bis hin zum System Model zusammenstecken.

Hat man erstmal sein Model gebaut, so kann man es über die registrierten Presenter  einfach zeigen. Desweiteren kann man es über die Data Extensions einfach suchen, einlesen oder abspeichern – ob in DB oder File. Schließlich kann man das Modell – eingebunden als Payload in der SurroundMessage – auf die Reise zu einer anderen Komponente schicken.

 

Dynamisch

 Das Surround Model erlaubt es auch, die Modelle zur Laufzeit dynamisch zusammen zu stecken – ohne konkrete Klassen zu programmieren (so läßt sich z.B. eine Applikation zur Lauftzeit per Script erweitern). Dies bietet ein großes Potenzial mit vielen weiteren Möglichkeiten.

 

Produktiv

 Wenn man Surround wie gedacht benutzt, gibt es kaum noch überflüssigen Code. Beim Presenter trifft das sofort zu, da man sich dann Unmengen an boilerplate UI Code sparen kann und man bekommt zusätzlich einen Common Look & Feel, da ein bestimmter Typ stets über den gleichen Presenter angezeigt wird.

Bei Surround Data kann man ein ebenso großes Potential ausschöpfen, allerdings nur wenn man den jeweiligen DataProvider generisch umsetzt, so daß jedes Surround Model ohne zusätzlichen Aufwand gesucht, eingeleseen und gespeichert werde kann. Dies ist besonders elegant bei vielen NoSQL Datastores möglicht, da Surrround JSON als Austauschformat out of the box unterstützt.

 Last but not Least: die Kommunikations Kanäle im SurroundMessaging:

Diese Abstraction ist wohl mit das beste, das ich jemals entwicklelt habe. Die benutzte Messaging Platform wird komplett gekapselt. So lassen sich nicht nur Messaging Frameworks anbinden, auch Webframeworks lassen sich integrieren. Es gibt eine automatische Übersetzung für das jeweilige Nachrichtenformat und eine einfache auf Surround basierende, den kompletten Lifecycle abdeckende, API.

 In der Regel wird man hierfür eine Code Generierung umsetzen. In der konkreten Implementierung merkt man dann sogar nicht mehr, daß man überhaupt eine Messaging Platform benutzt.

 

surround-concept.001

Follow

Visit Us On TwitterVisit Us On Youtube

Source Code

Instanttouch