In verschiedenen SOA-Projekten sind mir Bibliotheken oder Komponenten begegnet, die zentrale Datentypen enthalten, welche von allen Services verwendet werden können. Hier finden sich dann Typen wie z.B. Adresse oder Kunde wieder, die fachlich übergreifend sind und in verschiedenen Kontexten – sprich Services – verwendet werden. Schnell ergibt sich daraus ein Albtraum der Abhängigkeiten.Gibt es Änderungen an den zentralen Datentypen, müssen alle Services, die von ihnen abhängig sind, neu gebaut und in einer neuen Version produktiv gestellt werden. Versionierung von Datentypen ist hierbei noch eine ganz andere Herausforderung, auf die ich an dieser Stelle nicht eingehe. Die Sammlung dieser Datentypen wächst meist rapide an, da alle Typen, die in mehr als einem Service verwendet werden, zentralisiert werden. Mit der Anzahl der Datentypen steigt die Anzahl der Abhängigkeiten. Im Extremfall erreicht man eine fast schon monolithische Anwendung, wenn alle Services von den gemeinsamen Datentypen abhängig sind.
Doch was kann man dagegen tun? Man kann versuchen, möglichst wenige Änderungen an den zentralen Datentypen zuzulassen. Das wird in einer lebendigen SOA aber nicht funktionieren, und es wird über kurz oder lang Varianten der Typen in den verschiedenen Services geben. Die ehrliche Antwort lautet: Zentrale Datentypen sind in einer Service-orientierten Architektur nicht vorgesehen. Deren Prinzip ist ja gerade die lose Kopplung. Dazu steht eine vergleichsweise enge Kopplung der Services über gemeinsame Typen nun mal im Widerspruch.
Man sollte also jedem Service seine eigenen Datentypen spendieren, auch wenn sie fachlich identisch sind und dieselben Eigenschaften besitzen. Häufig ergeben sich zumindest feine Unterschiede, da jeder Service die Daten aus einem etwas anderen Blickwinkel betrachtet, sodass einzelne Eigenschaften irrelevant sind. Hinsichtlich persistenter Daten wird häufig dagegen argumentiert, dass diese in derselben Tabelle liegen und man deswegen schließlich auch ein und denselben Datentyp verwenden müsse. In diesem Fall liegt eine enge Kopplung der Services über die Datenbank vor. Dem kann ich in der Service-Schicht durch eine strikte Trennung der Services – und damit gegebenenfalls redundanten Datentypen – zumindest ansatzweise entgegenwirken. Aber eigentlich sollte ich dann die Schneidung meiner Services und/oder Persistenzschicht überprüfen, da die lose Kopplung konsequent bis in die Datenbank durchgezogen werden muss.
