Seit vielen Jahren verfolge ich schon den Ansatz eines Dynamic OOAD. Das Grundprinzip ist eigentlich recht einfach. Eine Domain Modellierung muß man auf jeden Fall entwickeln, es geht nicht ohne diese Basis. Wenn man nun allerdings weiter in Richtung UI, Datenbanken und Messaging denkt, gibt es oft einen Haufen boiler plate code der das ganze aufbläht und unnötig kompliziert macht.
 
Mittlerweile hat man herausgefunden, daß die Anzahl Fehler pro Codezeilen konstant ist: er liegt zwischen 15 bis 50 Bugs pro 1000 loc. Daher die einfache Rechnung: mehr Codzeilen auch mehr Fehler. Und die sind noch teurer als das unötighe Beiwerk. Es ist Minimal Coding angesagt.

 

Wenn man nun die Domain Klassen um View Constraints erweitert, erhält man ein ViewModel = Model & View. Naheliegend ist dann eine „Model View Presenter“ Architektur. Man kann – ausgehend auf Standard-Presenter – dann alle Modelle out of the box in einer Dynamic UI darstellen. Für spezielle Datentypen möge es auch einen speziellen registrierten Presenter geben, bei den meisten reichen die Basis Presenter aus. Wenn man dann pro unterstützte Platform (wie HTML5, Eclipse RCP, Java FX ….) die Presenter bereitstellt und damit auch das Typsystem. So kann man beliebig den „Kanal“ wechseln.

 

Das besondere an dieser Architektur ist, daß sich die konkreten Technologien so leicht austauschen lassen. Dies ist der Traum eines jeden Architekten, denn damit fallen Entscheidungen über die eingesetzten Technologien leichter da auch  das Risiko geringer wird. Für jede verwendete Techologie gibt es einen schlanken „Surround Adapter“, der mit so wenig wie möglichen Glue Code implementiert wird.

 

Allerdings heißt das auch, dass der „Business Code“ ausschließlich die Surround Adapter benutzen muss – kein direkter Zugriff ist erlaubt. Nur so kann man die Austauschbarkeit gewährleisten.

 

Meine derzeitigen Technologieen sind:

 

  • Das Domain Modeling werde ich in Java und TypeScript implementieren.
  • Als Dynamic UI werde ich Eclipse RCP und React benutzen.
  • Elasticsearch und OrientDB sind die ausgewählten Datastores.
  • Als Middleware wird akka und vertx eingesetzt.

 

Die Kommunikation wird auch darüber erfolgen – verpackt durch Surround Messaging. Dabei wird Messaging auch in der UI eingeführt. Somit wird das ganze System dann reaktiv mehr info unter:
Instanttouch Stay Reactive.