Creation of Data Classes from a reuse perspective: Enterprise/Organizational layer? Separate Component? How do I choose a Ruleset within a layer?
Look to implement classes in the layer that is visible by all applications that will leverage the capabilities encapsulated in that class.
Consider packaging Data Classes that pertain to a single capability in a Component that fully delivers the capability - functionality and data model - in isolation of where it is used. Connector integrations are a good use case for this.
Data Classes that span multiple capabilities across the Enterprise - and don't logically fit within a single Component - will benefit from being defined in Enterprise/Organizational layers.
If a data structure is clearly application-specific with no opportunity for re-use outside of that one application, then that is where it should be implemented, thereby rightly keeping application-specifics out of the enterprise layer.
Separate the "What application needs does the class fulfil?" question from the "Where should instances of this class be stored?" question. The latter is to be encapsulated in Data Pages that map between a logical data model (used by your applications) and a physical data model (used for persisting data inside or outside of Pega).
Business Partners - subject to the Intellectual Property considerations of their Clients - may consider implementing sets of Data Classes that fulfil solutions common to multiple Clients as Components. Naming conventions of these Component classes need to be mindful of adoption by multiple Clients.
Encapsulate classes that are dependent on each other to fulfil a capability into the same Ruleset. For example, Order, OrderLine and Product classes would have properties that reference each other, so these classes are likely packaged in the same Ruleset.