Here's a question that I'm often asked when I'm talking about business objects: how do you figure out what objects to create? It's a good question. Sometimes, objects are pretty obvious; a customer object in a sales system, for instance. Unfortunately, not all business objects are so obvious, and it can take some work to identify them.
It's always important to do a good job of analysis when we're developing any software; but it's even more critical when we're designing software using object-oriented techniques. Since one of the main aims in using objects and components is to promote reuse, it's important to identify and design our objects effectively.
There are plenty of books and articles that tell us all about rapid development and how we should quickly put together some objects and then let the object model evolve to meet future needs. This seems like an excellent idea; but unfortunately, this approach goes a long way toward defeating the reusability of the objects in the model.
If our evolutionary process requires that we change certain properties or methods that we've already added to an object, or that we must replace a single object with multiple objects, then we'll have to change all our client programs as well.
While it's true that we don't have to design every detail of our objects up front, it is very important that we identify our objects carefully. It's also very important that we get to the central behaviors of each object right from the start. The better the job that we can do during the analysis and design of our objects, the less risk we run of having to make substantial and costly changes later.
There are a number of approaches we can use to analyze and identify our business objects. These techniques include:
In an ideal world, we'd be able to design our applications without ever having to worry about an existing data model. And if we're lucky enough to be in this situation, we can start with our business object design and then build our data model to support our objects.
Since this is rarely an ideal world, however, it's much more likely that we'll be using an existing data source with a preset structure. But even in this case, we should still start by creating a business object model - with the understanding that we may have to compromise our model later on to fit it in with the existing database.
Using the CSLA, we can minimize the impact of the database design, since the data-centric business processing is handled separately from the objects that represent our business entities.