How does one design loosely-coupled systems which may often require data from each-other but don't necessarily belong in the same category?
For instance, lets take the old Pet-shop example one-step further and create a pet-store franchise. Each pet-store has its own website listing their contact information, promotions, and current stock.
The franchise owners want to have a listing of all the franchised pet-stores along with contact information and possibly a few photos available on their corporate site. They want to be able to update this information, and have any updates pushed automatically both-ways. They also want to provide the promotions information to all stores' sites in an automated way.
So, in this instance the stock lists are "owned" by the stores, and the contact information is part-"owned" by both entities, and the promotion information is "owned" by HQ. Due to arbitrary reasons all this data can't be stored in the same place.
Are there some best-practices or common strategies for coping with a situation like this?
I've been thinking about that problem, and I express it by saying that the relationships between classes are contextually determined. And any model that assumes global static associations (inherent coupling) between classes is problematic.
Another example I like to use is Products.
A Product can play a bunch of different roles. It's associated with an OrderItem, which is associated with an Order, which is associated with a Customer.
It's provided by a Vendor.
It's in a Catalogue, maybe by Section and Page.
It's the responsibility of a Buyer, with availability from multiple Vendors.
The ability to handle this complexity easily is the fundamental benefit of the Relational data model; and I've not seen it well dealt with in terms of OOP.
Aside: There's another ORM (Object Role Modeling, see VisioModeler, InfoModeler, etc.) that looks at the question from the Relational side, quite usefully (IMHO).
When you isolate yourself from the relationality of the database (by using CRUD generators, ActiveRecords, etc.) you are hiding this important aspect. (I think LINQ has the same problem, as well as introducing fundamental coupling problems, but I haven't worked it out very completely yet.)
I think you can successfully work your way through it if you're careful, but it becomes easy to embed coupling in the design, especially if you work from the database back to the rest of the application, rather than the other direction.