A good pointer is to follow the idioms of the language.If you're using classes, thinking of namespaces in terms of objects will make the language work for you, not against you. In this case, applying price patches (function) to a product array (object) is a transformation(function). Compare this with the : A ProductArray has got Transformers, and one of the Transformers is a PricePatcher. What these objects do (functions) is essentially encapsulated as an attribute of the objects themselves. For example, a FooPatcher can apply price patches to a product array too - but the language does not want you to think that way. The language forces you to think of objects interacting with other objects, and the details of the interaction are best left to the sensibilities of the objects themselves and should not leak out. Sorry if this got confusing!

A simple namespacing heuristic that I follow is that the hierarchy should read like a phrase when read from left to right (apply s's and other language idoms as necessary). For example : PricePatcher is a ProductArray's Transformer. Does that phrase make sense to you in your context?