Sometimes, isn redundancy and complexity necessary or even desirable? For instance, isn a large retailer more successful with thousands of redundant stores and massive complexity?
You can have as many instances (redundant retail stores) as you want in Row 6:Operations Classes, but you only want a single abstraction in Row 1:Scope Context, Row 2:Business Concepts and Row 3:System Logic. It is conceivable to have more than one abstraction in Row 4:Technology Physics and Row 5:Component Assemblies, but if you do, you have to keep track of them as they relate to Row 3:System Logic or else you will go out of control- potentially have an entropy problem. They will get out of sync. That is, you don’t want any discontinuity in the Concepts (Row 2) or the Logic (Row 3). It is conceivable that you might want to implement in more than one Technology (Row 4), but now you have a synchronization problem that you will have to manage. In terms of Row 6:Operations Classes instances, there can by “n” of those, but you want each instance to trace back to the Assemblies Transformation (Row 5), the Physics Transformation (Row 4), the Logic Transformation (Row 3), and the Concept Tra
