Support for Resource, DataTransferObject and Delegated operations in the PlantUML generator

[Adelrisk]

Is your feature request related to a problem? Please describe.
I enjoy the breadth and depth of support for the Sculpture concepts, such as the plugin syntax support for DataTransferObject and Resource The PlantUML generator doesn't seem as complete:

• Resource. Resources are currently ignored by the PlantUML generator.
• DataTransferObject. Also ignored, but PlantUML will render them implicitly (outside of the Aggregate) when referenced, such as in Service operations.
• Delegated operations. When an operation delegates to another (with the => syntax), PlantUML diagrams will only include the method name, ignoring return type and parameters.

Describe the solution you'd like
I believe the Class Diagram PlantUML generator should include the additional types Resource, DataTransferObject akin to ValueObject and Entity. (I am not concerned about colour choice.)

The delegated operations should probably be generated/rendered as copies of the original operation.

Describe alternatives you've considered
I cannot thing of any alternatives.

Additional context

• Definition of => http://sculptorgenerator.org/documentation/advanced-tutorial#services

  You can easily delegate to an operation in a Repository or another Service. Then you only have to declare the name of the operation. Return type and parameters are “copied” from the delegate operation.

• Documentation and example with DataTransferObject, Resource and delegated operations: http://sculptorgenerator.org/documentation/rest-tutorial#data-transfer-object

[stefan-ka]

Thanks for reporting the issue @Adelrisk!

You have a good point here; we should enhance the generator to support all the Sculptor types.
The current implementation focuses on the tactic DDD concepts only; which was our main requirement... As long as you stick to the DDD concepts while modeling your domain, you should be fine. But I agree that we probably should enhance this, since we adopted all the Sculptor concepts in our DSL.

[BenceSzalai]

DataTransferObject is also present in the CQRS example page, which is a bit confusing, since someone new to the tool trying out a tutorial may get confused why parts of the .cml did not made it into the .puml

[stefan-ka]

Tried to implement a quick solutions, but its not as easy as it looks because of Sculptors type hierarchy. A DataTransferObject does not extend DomainObject, which actually makes sense.

We have to think this through in more detail. At the moment I also question whether it makes sense to model a DTO inside an Aggregate, because it does not belong to a domain model. Maybe we should adjust the CML language here and only allow DTOs in the Application layer (could be part of a new grammar to map exposed domain objects to DTOs that are returned by application services). But also not 100% happy with that, because one could argue that DTOs belong to infrastructure. Resources definitely belong to infrastructure and indicate that one is doing something RESTful.