(08.07.04 07:30)

Isolation des Geschäftsmodells
Das Geschäftsmodell fängt das domänen-spezifische Fachwissen ein. Dieses Modell sollte Änderungen in der Technologie unbeschadet überstehen. Es muss daher so entworfen werden, dass es von der Infrastruktur (OS, GUI, Datenbank, ...) konsequent getrennt ist. Das Domänenmodell, welches den Kern des Systems bildet, ist in der Regel wesentlich beständiger als die verwendeten Technologien. Daher haben proprietäre Technologien im Geschäftsmodell nichts zu suchen. Zudem ist darauf zu achten, dass das Domänenmodell vollständig ist. Es ist daher zwingend zu vermeiden, Geschäftslogik im GUI oder in der Datenzugriffsschicht zu vergraben.

Tönt gut, ist nützlich und hinlänglich bekannt. Aber leider sieht die Realität oft noch immer so aus:

GUI-Code wird nicht auf der Basis von MVC entworfen und ist mit Magic-Pushbuttons übersät , soweit das Auge reicht. Geschäftslogik, View und Controller-Code werden munter gemischt, und die Testbarkeit tendiert gegen Null.

Das Geschäftsmodell verwendet lediglich technische Abstraktionen wie z.B. Container und Value Objects; es fehlen domänenspezifische Abstraktionen. Stattdessen werden oft direkt Typen und Implementierungen eines Persistenzframeworks zur Umsetzung der Business-Logik verwendet. Gerade .net und Entwicklungswerkzeuge wie Delphi begünstigen diese Technik. Auch hier leidet neben der Verständlichkeit die Testbarkeit erheblich.

Geschäftslogik landet in irgend einer Form in der Datenzugriffsschicht in SQL-Abfragen oder Stored Procedures. Das Domänenmodell ist dadurch unvollständig und verliert seine ordnende und erklärende Funktion.


Warum nur? Ist es denn tatsächlich ein frommer Wunsch, dass die Vernunft von ganz alleine siegen möge?

-nemo :-)

Über diesen Artikel diskutieren.

Zugriffe heute: 1 - gesamt: 4509.




Problemnahes Programmieren Problemlöser

Druckbare Version