Softwaremodularisierung - aber wie? - OIO
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Softwaremodularisierung
– aber wie?
Empfehlungen mit und gegen den Trend
Orientation in Objects GmbH
Weinheimer Str. 68
68309 Mannheim
www.oio.de
Version: 19.1 info@oio.de
Ihre Sprecher
Christian Dedek & Thorsten Maier
Trainer, Berater, Entwickler
Christian Dedek @ThorstenMaier
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 2
1
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 3
Anwender brauchen
keine Modularisierung
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 4
2
Modul
Modul
Modul Modul
Modul Modul
Modul Modul
Modul Modul
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 5
Modul
Modul
Modul Modul
Modul Modul
Modul Modul
Modul Modul
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 6
3
Modul
Modul
Modul Modul
Modul Modul
Modul Modul
Modul Modul
Modul
Modul
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 7
Router Service Search Service
Product Service
Meta Info Service
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 8
4
Kapselung
„Ich setze ein Modul in einem anderen Kontext ein
und es funktioniert nicht“
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 9
Cluelessness
„Ahnungslosigkeit“
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 10
5
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 11
Auswirkungen von
Modularisierung
„Mit Modularisierung kann
man kein Geld sparen“
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 12
6
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 13
①
Java
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 14
7
„Modularisierung“ in Java
• Compilation Units = Abstrakte Datentypen (Klassen, Interfaces) sind in Java grundlegende
Modultypen auf Sprachebene
– Members(fields, methods) sind für andere Module sichtbar
• Können ‚private‘ bzw. protected gekapselt werden
• Packages bilden auf Sprachebene einen Modultypus eines höheren Abstraktionslevels
– Package gruppieren abstrakte Datentypen
– Details der Datentypen werden verborgen/gekapselt
• können mit ‚public‘ Deklaration in die ‚Schnittstelle‘ des Package veröffentlicht werden
• Abhängigkeiten
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 15
Modulabhängigkeiten in Java
• Sourcecode definiert Abhängigkeit auf abstrakten Datentyp durch import Deklaration im
Modulconsumer
• Auflösung der Deklaration zu 2 Zeitpunkten relevant
– Compile-time
– Runtime
• Zuordnung des Datentyps wird final auf Compilation-Unit zurückgeführt
– Gruppierung der Compilation-Units in Verzeichnissen bzw. Archiven soll Konfiguration erleichtern
– Flexibles Zuordnen der .class-Resourcen durch Classpath-Variable möglich
• zu beiden Zeitpunkten
• In verschiedenen Umgebungen
• Laufzeitauflösung durch Classloader-Abstraktion erweiterbar
• Definition eines standardisierten Archivformats zur Gruppierung von Datentypen und Packages sollte
Modulbildung erleichtern
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 16
8
Modularisierung und Reflection
• Reflection ist ein Javakonzept zur metadatenbasierten Nutzung von abstrakten Datentypen
– erlaubt Flexibilisierung eines Modulconsumers gegenüber einem benutzten Modul
• unter Aufgabe der Typsicherheit
– dynamic Proxy ermöglicht sogar Flexibilisierung eines Modulproviders
• Leider durchbricht Reflection potentiell alle Modulkapselungen
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 17
Java – Vorteile
• Klare idiomatische Modulinterfacedeklarationen möglich
– public final class
– public final method
– public abstract class
– protected abstract method
• Hohe Flexibilität bei der Zuordnung von Modulen zu Modulconsumern
– viele mögliche Eingriffsvektoren über Classpathvariable
• Multiple URLS
• Konkurrierende Paketierung in Jars möglich
• Einfache Trennung von Compile Sets und Runtime Sets möglich
– Aktualisierung bzw. Bugfixing von Modulen zur Laufzeit durch Austausch der Compilation Unit sehr einfach
• Subclassing von Classloadern erlaubt komplexere Modularchitekturen
• Inkompatibilität von Modulconsumer und Modulprovider wird explizit (frühzeitig) abgefangen
– Compile-Time Fehler
– Laufzeit Exception
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 18
9
Java – Nachteile
• unklare bzw. schwer lesbare Idiome in Modulinterface nicht ausgeschlossen
– public, protected, public abstract members
– public interface
• keine Substruktur in größerer Packages möglich
– Subpackages heben die Sichtbarkeitsebene auf public(protected)
• kein Support für eine explizite Versionssemantik
– keine Information im Sourcecode
– keine standardisierte Semantik
• Trennung von Compiletime und Runtime Auflösung fehlerträchtig – sog.„JAR-Hell“
– Inkompatibilität von Modulversionen treten erst zur Laufzeit auf
– flexible Konfiguration erhöht potentielle Fehlerquellen
– erweiterbares Classloading kann zusätzliche Fehlerkategorien öffnen
• Moduldesign durch Reflection aushebelbar
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 19
Java – Zielarchitektur
• Grobgranulare APIs
– z.B. JDK, JEE bestehen aus schmalem Set von JARs
• keine komplexen modularen Sets als Zielsysteme
– Kleine Anzahl von JARS
– Keine tiefgeschichteten Modulabhängigkeiten
• Open Source Entwicklung
– Modulconsumer kann Deklaration des Modulinterface jederzeit einsehen
– notfalls selbst kompilieren
– Nutzung Modulen in voller Freiheit
• Auf eigene Verantwortung
• Versionierung unnötig bzw. binäre Abwärtskompatibilität von Modulinterfaces wird sichergestellt
– Klare Rollentrennung
• Modulprovider garantiert Kompatibilität
• Moduluser trägt Verantwortung für kompatiblen Modulset und ev. notwendiges Bugfxing
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 20
10②
OSGI
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 21
OSGI
• Erweiterung des Java Standards in einer formalen Spezifikation mit verschieden Implementierungen
– JAR-Files als sog. Bundles
• Erweiterungen in META-INF/MANIFEST.MF
– Bundlename
– Versionssemantik
– Import packages
– Export Packages Bundle: Main Bundle: Service
package package de.oio.service.api;
de.oio.application;
import
MeineAPI
Main
package de.oio.service.spi;
MeineImpl
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 22
11MANIFEST.MF als Moduldeskriptor
• in META-INF/MANIFEST. im JAR
– vgl. Java Standard
– Bsp:
– Manifest-Version: 1.0
– Bundle-Activator: de.oio.service.osgi.Activator
– Import-Package: javax.xml.bind,org.apache.commons.logging,org.osgi.framework
– Export-Package: oio.application.service.api;version=1.23
– Bundle-Name: oioservice
– Bundle-SymbolicName: de.oio.service-osgi
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 23
Abhängigkeitsdeklaration
• präferierte Abhängigkeitsbeschreibung über Import-Package Header
– Trennung von Abhängigkeitsdeklaration und package provider
– Zusätzlich Require-Bundle manifest header
• Eigentlich Antipattern
Import-Package:de.oio.service.api Export-Package: de.oio.service.api de.oio.service
de.oio.main:
Require-Bundle: de.oio.util
de.oio.util
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 24
12OSGi und Reflection
• Zugriff per Reflection über Bundlegrenzen ist generell genauso beschränkt wie typisierte Zugriffe
• DynamicImport-Package Header erlaubt Zugriff von reflektionbasierten Frameworks aus Bundles auf
Applikationbundles
– dabei entstehende Dependency Zyklen lösen ev. in OSGi lifecycle Sideeffect aus
• Erweiterung der Bundle Wiring API (Version 4.3) löst diese Problem
Bundle: AppModel
Bundle: Framework package de.oio.entity.api;
package
org.hibernate.reflect;
Export-Package: de.oio.entity.api
MeineEntity
DynamicImport-Package
EntityScanner package de.oio.entity.spi;
MeineImpl
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 25
OSGi und Versionierung
• Spezifikation einer strengen Syntax uns Semantik
– version ::= [ ‘.’ [ ‘.’ [ ‘.’ ]]]
• Berücksichtigt unterschiedliche Bedürfnisse von Modul Providern und Consumern
– Unter Berücksichtigung des Package Dependency Konzepts
• Bsp:
– Export-Package: com.acme.foo; version=1.2.3.201003030903
– Import-Package: com.acme.foo; version=“[1.2,2.0)”
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 26
13OSGI – Vorteile
• Klare Definition des Modulinterfaces
– Implementierungsdetails verborgen
• Laufzeitaustausch von Modulen
– dynamische Erweiterbarkeit von Systemen
– Updates/Bugfixing zur Laufzeit
• Support für inkompatible Modulversionen
– eindeutige Semantik und Deklaration im Modul und bei Dependency
– parallele multiple Versionen eines Moduls
– multiple OSGi Runtimes in einer JVM
• Ausgereifter Standard
– Version 7 Stand 2018 verfügbar
– Verschiedene Implementierungen
– 20 Jahre Entwicklung(6 Major Releases)
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 27
OSGI – Nachteile
• (ursprünglich) sehr hohe Lernkurve
– sowohl für Modulprovider als Modulconsumer
– historisch verbrauchtes Image
• Unglückliche Standardkonkurrenz zu Jigsaw
• teilweise eingeschränkte Nutzbarkeit von 3rd party JARs
– konnte zu Umpaketierung bzw. komplexen Zusatzkonfigurationen führen
• 3rd Party Jars als Bundle
• im Application Bundle
– Reflection bzw. Bytecodemanipulation durch 3rd party Libs/Frameworks problematisch
• Buildmanagement und IDE Support (war) beschränkt
• Fehlersuche ohne tiefes OSGi Knowhow aufwendig
– speziell Runtimechecks im Classloader
– Bundle Lifecycle Fehler
– mögliche Memory Leaks bei Nutzung in http-Sessions
• Versionierung mit Ranges kann bei großen Modulsets zu NP-vollständigen Problemen zur Laufzeit
führen
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 28
14OSGI – Zielarchitektur
• Komplexe Zielsysteme
– (sehr große) Modulzahl (OSGI ist toll, aber …
Flugzeug startet
OSGI-Container startet
Stabile Version des Autopilot-Moduls
dynamisch bestimmen
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 31
Auflösung der passenden Artefakte zur Build-Zeit
1.0
module-demo
moduleA moduleB
rootProject.name = 'module-demo' dependencies {
include 'moduleA', 'moduleB' implementation project(':moduleA')
}
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 32
16Build-System – Vorteile
• Gängige Build-Systeme unterstützen Multi-Module-Builds problemlos
• Relativ einfach
• Qualitätssicherung eines definierten Modul-Sets
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 33
Build-System – Nachteile
• IDE-Support ist brüchig
• Jede Änderung erfordert
– Rebuild
– Versionsnummer
– QA-Zyklus
– Deployment
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 34
17Build-System – Zielarchitektur
Java
Frontend
API
Java
Backend
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 35
④
Java Platform Module System
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 36
18© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 37
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 38
19© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 39
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 40
20Java 9 Module
• Java 9 definiert Module als neue Möglichkeit für die Strukturierung
– Module können Abhängigkeiten aufeinander definieren
• Die Sichtbarkeit auf beinhaltete Interfaces/Klassen kann selektiv erfolgen
– Kapselung über bisherige Sichtbarkeiten hinaus
Modul: Main Modul: Service
Main MeineAPI
MeineImpl
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 41
Exportierte Packages und Abhängigkeiten
• Andere Packages sind nur mit expliziter Deklaration einer Abhängigkeit zugreifbar
– Schlüsselwort „requires“ in Moduldeskriptor
• Trennung von Schichten durch Teilung in Module
• Zugriff auf Packages nur durch explizite Freigabe mittels „exports“
module java.base {
module de.oio.main {
requires java.logging; implizit exports java.lang;
exports java.util;
requires de.oio.util;
[...]
}
}
explizit
module java.logging { module de.oio.util {
exports java.util.logging; exports de.oio.util;
} }
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 42
21Transitive Abhängigkeiten
• Module haben Standardmäßig keinen Zugriff auf Inhalte von transitiven Abhängigkeiten
module de.oio.m1 { module de.oio.m2 { module de.oio.m3 {
requires de.oio.m2; requires de.oio.m3; exports de.oio.m3;
} } }
• Durch das Schlüsselwort „transitive“ bei einer „requires“ Deklaration wird Zugriff für abhängige
Module impliziert
module de.oio.test { module de.oio.util {
requires de.oio.util; requires transitive de.oio.api;
} }
transitiv module de.oio.api { direkt
exports de.oio.api;
}
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 43
Module und Reflection
• Zugriff per Reflection über Modulgrenzen ist generell eingeschränkt
– Exportierte Packages gewähren Zugriff auf „public“ Elemente
module de.oio.main { module de.oio.util {
requires de.oio.util; exports de.oio.util;
} }
• Schlüsselwort „opens“ gewährt Vollzugriff auf Elemente beliebiger Sichtbarkeit
module de.oio.main { module de.oio.util {
requires de.oio.util; opens de.oio.util;
} }
• „open“/„opens“ impliziert keine Sichtbarkeit auf Sprachebene
– Freigabe auf Sprachebene und für vollständige Reflection
module de.oio.util {
exports de.oio.util;
opens de.oio.util;
}
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 44
22Eingeschränkte Exporte
• „exports“ und „opens“ können auch nur für spezifische Module freigegeben werden
module de.oio.util {
exports de.oio.util to de.oio.main;
opens de.oio.util to de.oio.main;
}
• Spezifisches „exports“ notwendig zum Test von internen Klassen aus dediziertem Testmodul
• Spezifisches „opens“ notwendig für Frameworks, welche auf Reflection basieren
– Spring Framework
– JPA
– JAXB
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 45
JPMS – Vorteile
• Relativ einfache Moduldeklaration
– direkte Angabe der benötigten Module
• einfacher initialer Migrationspfad
– schrittweise Modularisierung ausgehend vom unnamed Module
• Ein abstrakter Datentyp existiert nur einmal
– JPMS prüft nur die Zugreifbarkeit
• Einfachere Fehlersuche
• Toolsupport scheint sich schnell zu entwickeln
• DI und Reflection konzeptionell bearbeitet
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 46
23JPMS – Nachteile
• Alle Module müssen auf den gleichen abstrakten Datentypen aufbauen
• keine Applikationsversionierung
– keine Semantik der Kompatibilität
• Version aus JDK
• keine Laufzeitaustauschbarkeit von Modulen
• Direkte Bindung an ein konkretes Modul statt möglicher Laufzeitevaluation
• Bisher wenig reale Praxiserfahrung
– z.B. DI/Reflection
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 47
JPMS – Zielarchitektur
• Modularisierung von Plattformen
– Bereitstellung definierter Subsets eines released Masters
• Einheitliches Entwicklungsteam der Plattform
– keine getrennten Releasezyklen der Module
– keine freie kombinierbarkeit von unterschiedlichen Releaseständen von Modulen
• Benutzer nutzt Plattformen als Sets von Kompatiblen Modulreleases
• Templating einer hierarchisierten Architektur
• Kapselung von Implementierungsdetails
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 48
24⑤
Microservices
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 49
Gefühlt wollen alle
Microservices mit
REST / JSON Schnittstellen
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 50
25Ist doch einfach, oder?
Sicherheit?
Logging?
Synchron / asynchron?
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 51
Versionierung?
Was sagt Roy Fielding?
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 52
26Quelle: https://www.slideshare.net/evolve_conference/201308-fielding-evolve/31
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 53
“Websites don’t come with version numbers […]
A RESTful API (done right) is just a website
for clients with a limited vocabulary.”
Quelle: https://www.infoq.com/articles/roy-fielding-on-versioning
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 54
27© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 55
Was immer alle vergessen
HATEOAS
Hypermedia as the engine of Application state
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 56
28© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 57
Niemand nutzt Hypermedia
“I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s
example is the SocialSite REST API. That is RPC. It screams RPC. […]”
“What needs to be done to make the REST architectural style clear on the notion that hypertext is a
constraint? In other words, if the engine of application state (and hence the API) is not being driven by
hypertext, then it cannot be RESTful and cannot be a REST API. Period.
Is there some broken manual somewhere that needs to be fixed?”
Roy T. Fielding, 2008, https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comments
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 58
29Wir brauchen einen „Chef“
Single Source of Truth
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 59
Wir brauchen einen „Chef“
Single Source of Truth
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 60
30Schnittstellen
Typgeprüftes Schnittstellenformat
TypeScript / Flow / Eine Sprache
„Compiler“
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 61
ACM Paper „Lessons from building static analysis tools at Google”
• „We advocate […] pushing workflow integration as early as possible“
• „When possible, checks are enabled as compiler errors“
– „[…] while [developers] are still amenable to making changes“
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 62
31Microservices – Vorteile
muss ich das wirklich noch erklären?
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 63
Microservices – Nachteile
„Modularisierung kostet Geld!“
Mehr Modularisierung kostet mehr Geld!
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 64
32Microservices – Zielarchitektur
Router Service Search Service
Product Service
Meta Info Service
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 65
Fazit
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 66
33Fazit
• Java bietet etwas, aber für manche Anwendungsfälle zu wenig
• OSGI hat viele tolle Features gebracht, ist aber aufwendig und erfordert gutes Tooling
• Über einen längeren Zeitraum haben sich viele mit Build-System-Modularisierung beholfen
• JPMS löst uns einige der alten Probleme
• Microservices bringen viel Nutzen, das allerdings zu hohen Kosten
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 67
Fazit
• Modularisierung nur bei konkretem Nutzen und nicht zum Selbstzweck
• Modularisierung kostet Geld! Nachträglich wird es noch teurer
• Modularisierung muss in Zeiten von Microservices trotz aller Agilität Up-Front eingeplant werden
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 68
34? ?? ?
Fragen ?
?
?
? ?
Orientation in Objects GmbH
Weinheimer Str. 68
68309 Mannheim
www.oio.de
info@oio.de 69
Vielen Dank für Ihre
Aufmerksamkeit!
Orientation in Objects GmbH
Weinheimer Str. 68
68309 Mannheim
www.oio.de
info@oio.de
35Kostentreiber
1. APIs
2. Unabhängigkeit
3. Transitive Abhängigkeiten
4. Versionierung
5. Build- und Konfiguration-Management
6. IDE-Support
7. QM-Prozesse
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 71
Adam Bien als Nostradamus
Konkret?
2019 PREDICTIONS
Oracle's move to opensource the entire JDK with tooling (even Java Mission Control) opened the market for third party companies like e.g. Amazon, RedHat or Azul Systems to provide
support. Also innovations like GraalVM keep Java interesting. Java popularity in OpenSource and Tiobe Language index should grow in 2019.
Serverless / Function as a Service is a fine-grained (Message Driven Bean / Command Pattern - like), interaction model. FaaS is widely overused, which causes complex applications to be
designed as distributed command pattern architecture. Such applications are hard to build, deploy, debug and profile. It might be too early for a backlash, but I would expect at least
some conference talks with titles like: "How to survive FaaS".
Kotlin is the programming language of choice for android development, what also helps with general adoption. Kotlin could become more popular in 2019, except Google manages to
release Fuchsia and Flutter and does not push Dart.
There is no logical explanation for building and deploying megabyte-sized WARs/JARs, when only a few kB change in each iteration. ThinWARs gained popularity in 2018, in 2019 they could
become even more popular. Making microprofile available on stock Java EE 8 application servers, makes the deployment units even smaller (microdeployments), faster and so more
productive.
Frequent releases, interesting innovation, conference presence will make microprofile even more popular.
Jakarta EE is gaining momentum and the project makes significant progress. The availability of jakartablogs.ee, JNoSQL and Eclipse GlassFish 5.1.0 will keep Jakarta EE in the news.
There is a common perception, that MicroProfile only works on esoteric runtimes. However, most "stock" application servers support Java EE 8 and MicroProfile without any additional setup,
download or configuration. The popularity of Java EE / Jakarta EE + MicroProfile (fusion) should grow in 2019.
After private cloud offerings (shipping servers to datacenters) Amazon's Outpost, Google's GKE, Microsoft's Azure Stack, private clouds should become more popular in 2019. I was too
early with the predictions 10 years ago, but now you can buy private clouds from public cloud vendors.
Microsoft, Google, Mozilla and others committed to use MDN as the canonical resource to describing WebStandards and Web API. The general availability of WebComponents, Service
Workers, Grid Layout, Fetch API, WebSockets, and ES 6 modules makes JavaScript frameworks optional. In 2019 I expect more projects moving away from JavaScript frameworks into
vanilla WebStandards.
The innovation in Java and frequent train releases, will make other JVM languages like e.g. Scala, Clojure less popular.
The use of external frameworks will further decrease in enterprise. Netflix stopped developing Hystrix, which will force many enterprise projects to migrate away from massive Hystrix-
boilerplate code, to either MicroProfile Fault Tolerance or resilience4j. Because the ecosystem is so rich, I expect more projects to collapse. 2019 could become the year of YAGNI.
Microsoft discontinued Edge and is going to use chromium what is a big move towards WebStandards in enterprise projects and also a reason to refactor exising projects by removing
optional frameworks.
kubernetes became the de-facto standard orchestrator. OpenShift is a popular kubernetes distribution, which is already surprisingly well adopted within enterprises. In 2019 OpenShift could
gain further adoption, also driven by the IBM's acquisition of RedHat.
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 72
36Was heißt Kompatibilität?
• Compile
– Gelinkte Schnittstelle
• Runtime
– Geladenes/resolved Module
– Getestetes Szenario
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 73
Richtige Modularisierungsentscheidungen
• Die korrekte ‚erste‘ Modularisierungsentscheidung aka Modularisierungstechnikentscheidung
entbindet nicht von der Verantwortung jeden folgenden Schnitt auf seine Korrektheit und
problemadäquate Ausführung zu prüfen
• Mögliche Fehler in der Ausarbeitung eines Modulzuschnitts
– zu feingranulare Schnitt
– starke Kopplung zwischen resultierenden Modulen (Kopplung)
– Mangelhafte Kapselung von Features in definierten Modulen (Kapselung)
• Fehler in der Ausarbeitung können den Nutzen eines Modularisierungsansatzes zerstören bzw. die
resultierenden Kosten unnötig erhöhen
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 74
37Exponierte API Probleme
• NP! Szenario bei inkompatiblen Versionen Lösbar?
• Ev. incompatibles Szenario diskutieren
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 75
Versionierungsprobleme
• Range Dependency
– NP! Beweis
• Vollständiges Repo als Lösung
Praxisprobleme?
– Polynomial
• Repo zur Compilezeit
– Fertig gelinkt paketieren
– Alternativ Dependencies vollständig paketieren
© Orientation in Objects GmbH Softwaremodularisierung – aber wie? 76
38Sie können auch lesen
