 |
(25.07.05 18.20)
Über die Vorzüge domänengetriebener Entwicklung mit Hilfe von Domänensprachen (DSLs) war an dieser Stelle schon mehrfach die Rede. Heute ist mir während des Schreibens eines Konzeptpapiers zu einer Endbenutzer-DSL ein schlichter aber wichtiger Punkt klar geworden:
API-Entwurf ist DSL-Entwurf. Bei beiden geht es um eine saubere Verwendungsschnittstelle, über welche die Abstraktionen eines Domänenmodells zielgerichtet, einfach und fehlerfrei angewendet werden können.
In Sprachen wie z.B. Smalltalk oder Ruby, die konsequent auf Selbstähnlichkeit beruhen, können API und DSL im besten Falle sogar nahtlos ineinander übergehen. In jedem Fall aber gilt für DSL und API, dass sie konsequent auf die Bedürfnisse der Anwender ausgerichtet werden sollten. Beide sind so zu entwerfen, dass Einfaches einfach und Schwieriges möglich ist. Damit das gelingt, müssen wir verstehen, welches Problem der Anwender der DSL oder der API lösen muss; hierfür müssen wir die Ziele der Anwender und ihre mentalen Modelle verstehen.
Genau deshalb ist ein Domänenmodell als geordnete Beschreibung einer Problemstellung so wichtig – egal, ob es sich hierbei um eine technische Domäne wie z.B. ein Framework für die Persistierung von Objekten handelt oder um eine anwendungsngsorientierte Domäne wie beispielsweise eine Finanzbuchhaltung. Die Schaffung eines schlüssigen und leicht verständlichen Domänenmodells zwingt den Entwickler in beiden Fällen dazu, sich mit den Zielen der Anwender auseinander zu setzten und sich auf ihre mentalen Modelle einzulassen.
API-Entwurf ist DSL-Entwurf. Für den Erfolg beider sind ausdrucksstarke Abstraktionen eingefasst in einem griffigen Domänenmodell die Voraussetzung.
-nemo :-)
Über diesen Artikel diskutieren.
|
|
