Folgende Punkte bzw. Fragen sollten beim Objektdesign berücksichtigt werden:

Der Objektorientierung liegt die Idee der Kapselung von Funktionalität und Daten in Klassen bzw. Objekttypen zugrunde. Implementierungdetails sollen dabei möglichst versteckt, also für den Anwender nicht sichtbar sein. Der Zugriff auf die in einer solchen "Kapsel" enthaltenen Daten erfolgt prinzipiell über vordefinierte Methoden und macht den Aufrufer unabhängig von den Implementierungsdetails.

Mit der Kapselung sind verschiedene Erwartungen verknüpft, wie z.B. eine bessere Wartbarkeit, Wiederverwendbarkeit und Änderbarkeit eines in dieser Weise strukturierten oder auch implementierten Software-Pakets. Die Kapselung erfolgt auch auf Komponentenebene. Die Kapselung ist Grundlage für eine Verteilbarkeit der Komponente, so daß die Komponenten in einem Business Framework integriert sind und getrennt gewartet werden.

Das Objektdesign ist eng gekoppelt an die Frage nach einer geeigneten Zerlegung eines Systems nach verschiedenen Verantwortlichkeiten. Die Zerlegung bzw. Kapselung soll dabei eindeutig und disjunkt erfolgen.

Jedes Business-Objekt ist für einen bestimmten Bereich verantwortlich und stellt die zugehörigen Services zur Verfügung. Die Services werden unter Berücksichtigung des zugrundeliegenden Szenarios in Form von Methoden spezifiziert. Objekt- und Methodendesign spielen eng zusammen und können nicht getrennt werden.

Business-Objekte können bestimmte Services anderer Business-Objekte in Anspruch nehmen, um ihre eigenen Services zu erbringen.

Pattern sind sinnvolle Designhilfen, die auf unterschiedlicher Ebene angewendet werden können. Auf Ebene des Objektdesigns stellt sich die Frage nach analogen betriebswirtschaftlichen Fragestellungen, z.B. Rückmeldungen zum Fertigungsauftrag sind auch für andere Auftragsarten in gleicher Weise sinnvoll. Die Anwendung von Pattern erfordert einen sehr guten Überblick über Anwendungsstrukturen. Ein häufig anzutreffendes Pattern ist das Head Item-Pattern. Dieses findet man bei Business-Objekten PurchaseOrder, SalesOrder, AccountingDocument usw.

Ein Objektdesign ist nur sinnvoll, wenn die Performance gesichert ist. Großen Einfluß auf die Performance hat die Objektgranularität und das Methodendesign. Die Gesamtkonsistenz des Business-Objektes wird maßgeblich vom verfügbaren Programmiermodell (Transaktionsmodell) bestimmt. Dabei müssen gewachsene Codingstrukturen berücksichtigt werden.