Open SemanticBeeng opened 5 years ago
Naming events explicitly is something we have looked into and its nice to know your requirement. In Baker release 3 this will be possible for you to do. Instead of firing any Object into Baker you always send in a RuntimeEvent into Baker. We then provide you a helper function to go from any Object to a RuntimeEvent. This is a little more verbose but simplifies Baker in general in our opinion.
Here is some example code (all names are still pending).
baker.fireSensoryEvent(processId,
RuntimeEvent.from(new SensoryEventToFire()))
Since you now fire a RuntimeEvent into Baker you are free to create a RuntimeEvent yourself. For example now you can:
RuntimeEvent runtimeEvent = new RuntimeEvent("domain.SensoryEventToFire");
baker.fireSensoryEventReceived(processId, runtimeEvent );
or
RuntimeEvent runtimeEvent = RuntimeEvent.from(SensoryEventToFire.class)
.copy("domain.SensoryEventToFire");
baker.fireSensoryEventReceived(processId, runtimeEvent );
You are then also free to create your own helper functions to create RuntimeEvents the way you described it.
Please let me know what you think of this.
Interested to have the ability to name events explicitly instead of the name assumed to be the
Class.getSimpleName
.This would improve the communication through visual representation of recipes by naming events to include
bounded context
s (context ofDomain Driven Design
).Area of code clearly related:
https://github.com/SemanticBeeng/baker/blob/53504b24ae22a9b0084281b9dd517f2a86e843cc/runtime/src/main/scala/com/ing/baker/runtime/core/Baker.scala#L43-L49
Thinking to introduce a configurable
EventNameExtractor
mechanism. Of of the possible implementations would be look fordef name
orval name
in the class.Would you welcome this?