Business objects can quickly scale in complexity, especially in a true object-oriented model. Containment relationships mingle with implementation and interface inheritance to make a complex web of objects. A few simple implementation details can help maintain the business object in the long term and help guide how you think about business objects:
Flat business object structures translate to other representational models better: In enterprise systems, your object-oriented application is not the only application deployed. Frequently, legacy applications that do not employ object-orientation are in play. Often, the mechanism for communicating with these applications will be through the database. Although database systems are not necessarily equivalent to flat object-oriented structures, they are also not as rich with inheritance. Keeping alternative representations of your data in mind will help with integration scenarios. Although object purists will cringe when I say this, acknowledging the relationship between relational models and object-oriented systems is important. If you have trouble representing your objects in a relational database model, your structure is probably too rich for an environment where you have to integrate your application with other platforms.
Most business objects have an element of persistent data: The reality of persistence is often that the structure of a business object can hurt performance and make the administration of the data relationships to the objects difficult to maintain. Be cognizant of the model you will use and the impact on performance that your design decisions will have.
You should offer interfaces on the service implementation for all contained and indirectly contained data: Further, rather than exposing the implementation details of a particular complex data type, it is typically easier and better to offer a set and get method for the entire complex type ( setJavaBean , getJavaBean ). This technique allows the JavaBean to change structure without affecting the operations on the service implementation if you had elevated the JavaBean properties into the service implementation interface. For example, you may be inclined to add methods such as setAddressLine1 on the business object instead of a single method that sets the entire address. The latter is a better way to handle the interface modification.