I'm sure you are familiar with the Value pattern, and possibly the Dependent Value pattern for coarse grained BMP.
My question is, where does the business logic for validating a value-object go? The quick answer would be, "The bean stupid!" but that answer does not take into account the fact that value objects may be shared across multiple beans. I might have an EJB named WorkOrder for a shipping company. The WorkOrder may have Destination (Address), PickupLocation (Address), and many Trip's. I might also have, for driver settlement, an EJB named DriverWorkWeek with many Trips. Finally I might have an EJB named Customer with a few Addresses and other info.
With this confusing example, hopefully you can see that sometimes a value object is dependent (composition) and sometimes they are independent (association). With dependent value objects the business logic can always be placed in the EJB, but with independent value objects they are CRUD (Created, Read, Updated, Deleted) from multiple components thus it does not make sense to put the business logic in any single EJB. If we did so, we would wind up duplicating the code in each EJB that CRUD'ed the value-object.
An Address, or a Trip object is not coarse grained enough to warrant a BMP of it's own so we can't put the logic in the value-object itself. The other option is to create a reusable class for each value object containing validating code. I imagine this class implementing an interface "Validator" with a function .validate(Validatable) or something along those lines.
So to restate my question, where does the logic go? Which approach is best? Is there another, cleaner implementation of logic for a value-object?
