MVP implementation for Groups

[anton-kasperovich]

By no means this is a proper implementations for Groups, but I would like to kick off discussion on how owners of the Azure-PlantUML would see it should be implemented correctly. The codebase which I have in PR does work (not the best UI and will be improved), but obviously making if statement to split "entity/group" is not great.

Could you please have a look and guide on how would you see this should be done to be accepted?

P.S. 100% inspired by AWS PlantUML, kudos to @mcwarman

[Potherca]

As co-maintainer I'll have to defer to @travisnielsen and/or @RicardoNiepel for any final say.

That said, I don't see any major downsides in adding support for grouping.

I do wonder if/where a definitive list is available of what constitutes a "group"?

As for the implementation, there are indeed some rough edges that need refining (for instance the use of positional parameter instead of named parameters) but those can easily be address by the regular review process.

For me, the major omission at this point is documentation that describes the usage of and motivation behind having "groups". What are they good for? When to use them? How to use them? Which groups should be used for what? How to add/create custom groups? Etc.

Obviously, backward compatibility is desirable. We might want to set up testing (similar to the Percy testing as currently done in C4-Plantuml).

[travisnielsen]

I think of this as parent / child nesting, which is an important part of any cloud deployment diagram and, technically speaking, is already supported in PlantUML. Last year I had looked into ways to improve the layout this by adding overrides that simplify parent objects. This approach doesn't introduce the idea of a different object type for groups because so many Azure services could have parent containers (App Service Plan, Event Hub clusters, etc...). It also doesn't require changes to the sprite generation code. In any case, this is what I ended up with:

The tradeoff in my POC implementation is the need for 'null' values in parameters.

In any case, I can see the benefits of this approach in terms of clarity, but it comes with a need to define all the object types that could conceivably be a group. If the idea is to keep support limited to a handful of items like Subscriptions, Resource Groups, and VNETs, I suppose this would be a nice addition to Azure PlantUML.