particular / eshoponcontainers Goto Github PK

Regular iterative development of the project is cumbersome within Visual Studio. Connections often get lost to containers or Rabbit and intermittent errors arise sometimes requiring the project to be restarted or, in some cases, deleting the containers and recreating them.

Also, in a real life scenario, we would not likely develop a solution in this way. Docker is more or less a deployment concern so the solution should be developed locally as you normally would and the process of running in Docker would usually happen as a separate process.

I propose we create an .sln file geared to this way of working.

PoA

• NServiceBus

  • Routing configuration
    • Add snippets from the solution to illustrate how it's configured
  • Describe

• Transport

  • RabbitMQ

• Persister

  • Cover in memory persistence that we're currently using
  • Cover SQL Persistence when it's added
    • Explain how to configure/create dbs in Docker
    • Explain that scripts are auto-executed, but can (should?) be disabled in production

• SI

  • Explain how to set it up
  • Add screenshot with visualization

• SP

  • Explain how to set it up
  • Add screenshot with visualization

• Serialization

  • Explain behavior to fallback on type of message, because contracts aren't shared.
  • Explain this is a deployment issue and doesn't have to be 'decoupled' in VIsual Studio.

• Outbox

  • Catalog Service
    • Removed EventLog and enabled NServiceBus Outbox
      Especially check OrderStatusChangedToAwaitingValidationIntegrationEventHandler as it's extremely easier than before.
    • IntegrationEventMigrations removed.
  • Ordering Service
    • IntegrationEventMigrations removed.

Is there any advanced sample like this with Windsor IoC?
Or can please guide me what I need to migrate your sample to Windsor

Plan of Attack

• Basket
• Catalog
• Location
• Marketing
• Ordering
• Payment

• Store data on incoming UserCheckoutAcceptedIntegrationEvent and publish event to trigger saga
• Add timeout in saga and upon receiving timeout, publish GracePeriodConfirmedIntegrationEvent
• Receive OrderStockRejectedIntegrationEventHandler inside saga
• Receive CancelOrderCommand inside saga
• Process OrderStockConfirmedIntegrationEvent correctly. Not 100% sure on how this works
• Check any other events that seem like infrastructural events, might need to replace these with business events. It's either cancelled or not.

Finally this should work

• Happy path where orders are simply successfully ordered
• Path where orders are canceled by user
• Path where orders are canceled because we're out of stock
• Path where payment isn't successful.
• Clean up
• Tests

Instead of copying the message classes between the various services, something similar can be achieved without creating a shared message assembly - use Linked Files to have a single copy of the message classes.

If this path is chosen, the Readme should also be updated.

• Use proper tag 2017-GA
• Use proper environment variable for password MSSQL_SA_PASSWORD

In preparation for sagas, @dvdstelt and I followed the path of an order. Given the complexity of the code, I thought I'd document it at least in an issue first and we can figure out if we want to do anything with it.

Much of this will change with the saga implementation for orders but here's what we have so far:

• User checks out an order. This triggers a UserCheckoutAcceptedIntegrationEvent
• UserCheckoutAcceptedIntegrationEventHandler
  • publishes OrderStartedIntegrationEvent event, which empties the shoppingbasket in Basket service.
  • creates and publishes a CreateOrderCommand Mediatr command
• CreateOrderCommandHandler creates an Order and saves to the database
• GracePeriodManagerService runs as an IHostedService. Every 30 seconds (by default), it checks the database for submitted orders where the grace period (by default, 1 minute) has ended. For each order, it publishes a GracePeriodConfirmedIntegrationEvent
• GracePeriodConfirmedIntegrationEventHandler updates the order status to AwaitingValidation. Besides updating the orders status, this also adds an OrderStatusChangedToAwaitingValidationDomainEvent to the Order aggregates internal list of domain events
• GracePeriodConfirmedIntegrationEventHandler then saves the order to the database.
  • IMPORTANT: When saving the order, OrderingContext also dispatches any pending domain events
• OrderStatusChangedToAwaitingValidationDomainEventHandler kicks in, verifies stock, then publishes OrderStatusChangedToAwaitingValidationIntegrationEvent
• OrderStatusChangedToAwaitingValidationIntegrationEventHandler (in Catalog.API) checks stock and publishes OrderStockRejectedIntegrationEvent or OrderStockConfirmedIntegrationEvent accordingly

Stock rejected

• OrderStockRejectedIntegrationEventHandler collects rejected items, sets order status to Cancelled, and saves the order. No other work is performed

Stock confirmed

• OrderStockConfirmedIntegrationEventHandler sets the order status to "confirmed" which adds an OrderStatusChangedToStockConfirmedDomainEvent to the order aggregate.
• OrderStockConfirmedIntegrationEventHandler saves the order which triggers the domain event in the previous step in Mediatr
• OrderStatusChangedToStockConfirmedDomainEventHandler publishes an OrderStatusChangedToStockConfirmedIntegrationEvent
• OrderStatusChangedToStockConfirmedIntegrationEventHandler (in Payment.API) publishes either OrderPaymentSuccededIntegrationEvent (sic) or OrderPaymentFailedIntegrationEvent
• `OrderPaymentFailedIntegrationEventHandler marks the order as cancelled and saves it
• OrderPaymentSuccededIntegrationEventHandler marks the order as paid, which adds an OrderStatusChangedToPaidDomainEvent to the order aggregate. The handler then saves the order which triggers the domain event.
• OrderStatusChangedToPaidDomainEventHandler triggers an OrderStatusChangedToPaidIntegrationEvent
• OrderStatusChangedToPaidIntegrationEventHandler (in Catalog.API) updates the stock

Are there plans to consolidate all the changes done on the main eShoponContainers repo to this or maybe even consider opening a PR to move the NServiceBus implementation to the original repository?

Waiting for this #15.

PoA:

• Explain how to set up monitoring with SI/SC/SP
• Quick (one paragraph) intro to SI/SC/SP
• Capture screenshots and describe the visualizations from SI
• Capture screenshots and describe the visualizations from SP
• Add visualizations to the main Readme file with link to more detailed info above

Some things I noticed that could be improved in the Readme include:

• Links to ServicePulse and ServiceInsight here: https://github.com/Particular/eShopOnContainers#monitoring-and-visualization-tools
• Link to documentation on unobtrusive mode

Currently some events are published outside of the handler and conversation ID is not preserved.