The test endpoints used to create an order, add a product, confirm the
order and ship it are not embracing the asynchronous approach of the
CommandGateway. Make sure that all commands are composed with one
another and return the completable future for Spring to resolve
#BAEL-4767
Change PlaceOrderCommand/OrderPlacedEvent to
CreateOrderCommand/OrderCreatedEvent. Placed suggests it is already
placed, meaning products cannot be changed. However with the new
OrderLine member and its operations it's no longer correct to state the
order placed upon creation. Furthermore, the OrderedProduct is no longer
a single product, but contains several. Renaming this to Order is more
in line with what this query model resembles
#BAEL-4767
Add test cases to reach a 100% coverage of all message handling
functions of the OrderAggregate and OrderLine member. Added, upgrade to
JUnit 5
#BAEL-4767
Adjust the OrderAggregate to contain an OrderLine aggregate member. The
OrderLine is added as soon as a Product is added through the
AddProductCommand. The OrderLine member is capable of handling the
increment and decrement product count commands, to increase/decrease the
number of instances for that OrderLine. Decreasing the count below 1
will publish the ProductRemovedEvent from within the OrderLine.
Additional business validation is added to unsure a given Product isn't
added twice (adding a second should go through increment) and that the
products aren't adjusted as soon as the product is confirmed.
#BAEL-4767
- Introduce a DuplicateOrderLineException to signal whenever somebody
wants to add the same product twice instead of using the increment
command.
- Introduce OrderAlreadyConfirmedException to signal whenever the order
is confirmed, so that adding products and incrementing/decrementing
their count is not possible once the order has been confirmed
#BAEL-4767
- Adjust OrderPlacedEvent to only construct the order
- Introduce ProductAddedEvent to be able to add several products
to a order
- Introduce ProductCountIncrementedEvent to increase the number of
product instances for a given Order
- Introduce ProductCountDecrementedEvent to increase the number of
product instances for a given Order
- Introduce ProductRemovedEvent to signal whenever all the product count
drops below 1
#BAEL-4767
- Adjust PlaceOrderCommand to only construct the order
- Introduce AddProductCommand to be able to add several products to an
order
- Introduce IncrementProductCountCommand to increase the number of
product instances for a given Order
- Introduce DecrementProductCountCommand to increase the number of
product instances for a given Order
#BAEL-4767
Add the ProcessingGroup annotation to OrderedProductsEventHandler so
that this event handler is grouped in a nicely named Event Processor.
If the app is started in conjunction with Axon Server, this will make
the set up more evident from the dashboard
BAEL-2435
Update the Axon Framework version to 4.1.1. Additionally, drop the
exclusion on axon-server-connector, as the page will be adjusted to
use Axon Server SE.
BAEL-2345
-Add toString() function to messages/query-model
-Fix typo in exception
-Reorder event handlers in OrderedProductsEventHandler
-Replace usage of constants for local fields
-Add missing Aggregate test case
Introduce a FindAllOrderedProductsQuery query message, which is
published on the QueryGateway through the OrderRestEndpoint and handled
by the OrderedProductsEventHandler
Change the domain from 'Messages' to 'Order' as that domain is better
suited for an example project like this. The Query Model would be better
suited to revolve around the OrderedProducts rather than just printing
out a line of text. To that end, add a OrderedProduct model with the
OrderStatus, which is updated in the (renamed)
OrderedProductsEventHandler upon all the events
Change the domain from 'Messages' to 'Order' as that domain is better
suited for an example project like this. Update the endpoint to reflect
the order focus i.o. the message focus. Additionally, add a POST
endpoint which would return an exception due to the state check in the
aggregate
Change the domain from 'Messages' to 'Order' as that domain is better
suited for an example project like this. To that end the
MessagesAggregate should be replaced by an OrderAggregate. Additionally,
add some decision making logic which denies the shipping of an order if
it hasn't been confirmed yet. Adjust and update thee unit test
accordingly
Change the domain from 'Messages' to 'Order' as that domain is better
suited for an example project like this. First, update the commands and
events, adding an extra command/event to flesh out the domain some what
Add JPA and H2 dependencies to allow event sourcing, as for event
sourcing and EventStore is mandatory, and to make an EventStore a
database needs to be present for Axon's auto-configuration
-Add spring-boot-starter-web to support rest endpoints
-Add a rest endpoint to spoof some form of UI to publish a message, as
the old main will no longer publish the commands upon start up
-Change TargetAggregateIdentifier import statement to the new location
-Add equals/hashcode as best practice for commands and events
-Add description
-Change parent to parent-boot-2 to leverage a spring boot start up
approach
-Replace old import statements for the new locations
-Mark the aggregate as @Aggregate to make it autowired through the
spring boot starter
-Move all command handlers/decision making functions to the top of the
file
-Rename the command handler to `handle` as a best practice for command
handlers
-Use @EventSourcingHandler i.o. @EventHandler as a best practice for
event handlers in Aggregates, as those only are used to 'source' the
aggregate
-Update test case according to latest standards
-Add description
-Change parent to parent-boot-2 to leverage a spring boot start up
approach
-Replace core dependency for axon-spring-boot-autoconfigure excluding
axon-server as we cant start that up for this use case
-Add spring-boot-autoconfigure dependency
-Adjust the axon version to 4.0.3
