Yes, and it works when three rules are respected. A domain business object toolkit per domain (Customer, Order, Claim ...) holds the shared business objects, their validation services and converters; every process app depends on the domain toolkits it needs.
- Additive changes only in a released snapshot line - add fields, never rename / retype / delete: a dependent app upgraded to the new toolkit snapshot must not break its mappings, coaches or running instances (instance migration keeps working when types only grow). Breaking changes go into a new BO (OrderV2) or a new major toolkit line with a conversion service.
- Small toolkits, no cycles - one toolkit per domain, a tiny "common" toolkit for the truly shared things (Address, Money, Identifier); domain toolkits may depend on common, never on each other. A single company-wide BO toolkit becomes the bottleneck everyone waits for.
- Owner and release cadence - one team owns each domain toolkit, snapshots have semantic versions (1.4.0), changes are announced with the diff (BAW's snapshot comparison), and apps upgrade on their own schedule (they pin a snapshot).
What to put next to the BOs: the JSON / XML converters for the integration formats of that domain, the validation service (validateOrder), sample data for playbacks, and the coach views that render the object (an Order Summary view) - the object and its UI travel together. What not to put there: process-specific BOs (keep them in the app), environment configuration (question 766), integration server definitions.
On CP4BA the same governance applies; Business Automation Studio shows the toolkit dependencies per project, which helps enforcing the "no cycles" rule.
References