There is always scoping as we need to know how a property specified at the cluster or domain level applies to the server as in the example of system or jvn properties. There its straightforward; the more specific value overrides the more general.
We have not talked about cluster or admin domain metadata, I mean a, so I view your example as just introducing that notion.
The various domain model elements map onto a ManagedComponent in a way that need to be clearly defined. Logically I stil think about it in terms of scopes that have to be applied to a piece of deployment metadata, and each layer adds the opportunity to specify a default that can be overriden by a more specific value.
So, looking at your little fragment, a clustered-service at at group (which I'm thinking of as admin-domain notion), is a specification of clustering aspects that hae to be applied to a bean or spec component. The resource element is a profile default saying that the profile that maps to the "
Production" group should include a "Production DB" jca factory.
This is our initial major challenge to moving to the domain model. We need a mapping from domain metadata namespaces onto a ManagedComponent/ManagedProperty. There can be multiple domain metadata namespaces mapping onto a given ManagedComponent/ManagedProperty.