As the event-planning application grows, individual classes are becoming less interesting than the relationships between groups of classes. I have already spent considerable time thinking about Guests, Groups, Tables, Chairs, contact information, the Event Document and the graphical objects used to describe a venue. Each of those concepts can be designed reasonably well in isolation. But a collection of well-designed classes does not automatically produce a well-designed application. The next question is architectural: How should all these classes be organised so that the business data, graphical representation, user interface and business rules do not gradually become one enormous interconnected structure? This is particularly important for a desktop application because the same underlying information may appear in many places at the same time. A Guest may appear in a Guest list. The same Guest may appear as a name beside a Chair on the floor plan. ...