Good point: why use Being, which is new, instead of an industry-proven framework?
Being is a library, not a framework. It's purpose and scope is not messaging infrastructure, but developer experience. So it doesn't reinvent the weel, but builds on preexisting, proven infrastructure (Vlingo).
Axon is a good example, since it's quite developer-friendly as well. But it also ties you to a lot of framework details. And it comes with a learning curve if you want to get started.
(I'm not talking about the essential complexity of event sourcing, but the accidental, framework specific complexity.)
The @AggregateIdentifier is the external reference point to into the GiftCard Aggregate. This field is a hard requirement. [...]
Note that the Aggregate Identifier must be set in the @EventSourcingHandler of the very first Event published by the aggregate. [...]
The property on the payload that will be used to find the entity that the message should be routed to, defaults to the name of the @EntityId annotated field. For example, when annotating the field transactionId, the command must define a property with that same name, which means either a transactionId or a getTransactionId() method must be present.
And so on. I know I have taken these texts out of context, so they'll naturally be harder to understand. My point is: you have to learn and comply to all of these framework specific, non-obvious rules. This will make it harder to get started, and they'll likely be different from framework to framework.
If you look further in the documentation, you see that the authors even promote using event handlers for aggregate internal classes - which not only tightly couples them to the Axon framework, but also breaks with the DDD idea that the Aggregate Root can enforce consistency boundaries.
In essence, event sourcing is just two functions:
(command, state) -> event(s)
(event, state) -> new state
Using Being, you can define these as Java functions. You can test the state change as plain unit tests, without going through any infrastructure.
So - Being is like a developer-friendly facade for messaging infrastructure. Like SL4J is for Log4j. Today, it only supports Vlingo. Tomorrow, it may well be that it will support Axon as well, as an alternative.
The reason I chose Vlingo is that it is internally based on the Actor Model, which avoids some nasty concurrency problems. (I would have to look at Axon in more detail to see how this is dealt with there.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Did you look at other existing Java libraries that do the same? I'm a bit familiar with the Axon Framework, and being seems very similar to it.
Good point: why use Being, which is new, instead of an industry-proven framework?
Being is a library, not a framework. It's purpose and scope is not messaging infrastructure, but developer experience. So it doesn't reinvent the weel, but builds on preexisting, proven infrastructure (Vlingo).
Axon is a good example, since it's quite developer-friendly as well. But it also ties you to a lot of framework details. And it comes with a learning curve if you want to get started.
(I'm not talking about the essential complexity of event sourcing, but the accidental, framework specific complexity.)
Here are a few quotes from the official documentation:
The @AggregateIdentifier is the external reference point to into the GiftCard Aggregate. This field is a hard requirement. [...]
Note that the Aggregate Identifier must be set in the @EventSourcingHandler of the very first Event published by the aggregate. [...]
The property on the payload that will be used to find the entity that the message should be routed to, defaults to the name of the @EntityId annotated field. For example, when annotating the field transactionId, the command must define a property with that same name, which means either a transactionId or a getTransactionId() method must be present.
And so on. I know I have taken these texts out of context, so they'll naturally be harder to understand. My point is: you have to learn and comply to all of these framework specific, non-obvious rules. This will make it harder to get started, and they'll likely be different from framework to framework.
If you look further in the documentation, you see that the authors even promote using event handlers for aggregate internal classes - which not only tightly couples them to the Axon framework, but also breaks with the DDD idea that the Aggregate Root can enforce consistency boundaries.
In essence, event sourcing is just two functions:
(command, state) -> event(s)
(event, state) -> new state
Using Being, you can define these as Java functions. You can test the state change as plain unit tests, without going through any infrastructure.
So - Being is like a developer-friendly facade for messaging infrastructure. Like SL4J is for Log4j. Today, it only supports Vlingo. Tomorrow, it may well be that it will support Axon as well, as an alternative.
The reason I chose Vlingo is that it is internally based on the Actor Model, which avoids some nasty concurrency problems. (I would have to look at Axon in more detail to see how this is dealt with there.)