Im Business Object Repository werden die Objekttypen (Klassen) der Business-Objekte definiert und verwaltet. Die Schnittstelle einer solchen Klasse besteht aus einer Liste von Attributen und Operationen; eine Operation besitzt eine Liste von Parametern. Die Aufgabe besteht nun darin, eine Verwaltungskomponente für die Klassenschnittstellen zu entwickeln. Aufgrund der vorliegenden hierarchischen Strukturierung dieser Daten, bietet sich eine Konstruktion basierend auf dem Composite-Muster [5] an. Im ersten Ansatz würde der Entwurf wahrscheinlich wie in Bild 1 aussehen.
Bild 1: Erster Strukturierungsansatz
Die Übertragung des Musters in den Entwurf (Schritt 2) führt zu dem Ergebnis, daß sich Attribute und Parameter der Business-Objekte unter der Sicht der hier gestellten Anforderungen nur gering unterscheiden und so eine Aufteilung unnötig ist. Als strukturelle Änderung (Schritt 3) ergibt sich, daß auf eine Leaf-Klasse gänzlich verzichtet werden kann. Statt dessen wird Component zu einer konkreten Klasse. Die Flexibilität des Musters wird hier also aus Gründen der Einfachheit bewußt verringert. Es sei angemerkt, daß die nachträgliche Erweiterung wieder leicht möglich ist durch die erneute Einführung von Leaf-Klassen. Das Potential des Musters bleibt somit erhalten. Um flexibel gehaltene Teile eines Entwurfs später leicht identifizieren zu können, ist eine Dokumentation, die von der Musterausprägung ausgeht, besonders geeignet.
Schritt 1: Auswählen eines
Entwurfsmusters, das auf die Anforderungen paßt 
Schritt 2: Übertragung des
Musters in den Entwurf 
Schritt 3: Strukturelle Änderungen des Musters
bei der Ausprägung
Schritt 4: Die technischen
Klassen einführen
