Before this update, there were only two levels of hierarchy that we managed. A class would be a big node and inside it we'd have smaller nodes for all the methods of the class. But that's not how real life diagrams are represented.
Introducing, folder structure based hierarchies. There are two reasons why we chose this approach:
- Keep code vanilla, don't add anything custom.
- Using a folder structure to create boxes around boxes forces you to define better boundaries.
Explanation
Using code to create diagrams and by extension a design of the system, is amazing for a few reasons but we believe the best one is 'Foresight'. You can see and visualise what the structure of the code would be from the get go.
And hence that should be reflected when you are trying to create boundaries(or hierarchies).
Because what's a folder, if not a repository masquerading?