I think the idea of a catalog/spec object (Vehicle) could be the way to go. The only mandatory parameter for the customer would be Type everything else could by optional i.e. defaults. The default colour could be, say, black. :-) Validate, give it an id, a date and add to a Vehicles object (front end to a db).

Pass the Vehicle->id to whoever needs it. Extra parameters could be added and validated at each stage of the chain and passed on along.

The Vehicles object would allow querying of the db by each part of the chain to establish, say, how many cars, how many bikes. Pass Vehicles an id and get a Vehicle back, perhaps to check the status, e.g. not started, started, completed. The Vehicle_Builder might want to know what new orders have come in today (Vehicles->today). The Car_Builder would want to know if the paint shop has to get a different pot of paint from the store (grrr! customers!!).

Adding a layer of abstraction has reduced all the parmaters to one, the id. It's all been encapsulated in black boxes. Neither Vehicle nor Vehicles know or care about customers, dealers, builders (boo introspection! :-). They know about colours and dates but little else.

While you're at the paper and pencil stage is a good time to nail down the APIs. Hard. I believe the API is key, get it right and the code writes it self. Well chosen object names and methods and the code will "read" well too. And it will be short, a good thing, but be careful not to put the business model (logic) in the objects or you could find yourself in a straight jacket. Get those flow charts right first!

The above is the extent of my experience with OO, so, while no expert I have found this much very helpful. The discussion in that thread is also very useful as it takes up the question of how much you put in an object.

And, of course, there are many other ways to do it :-)

Good luck!