diff --git a/Roadmap-and-Milestones-for-future-releases.md b/Roadmap-and-Milestones-for-future-releases.md index 3047c39..631e3dc 100644 --- a/Roadmap-and-Milestones-for-future-releases.md +++ b/Roadmap-and-Milestones-for-future-releases.md @@ -4,26 +4,33 @@ /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// - Implement support for Windows Containers running on Windows NanoServer using different Docker base images instead of the Linux based images (.NET Core code should be the same as it is cross-platform) - Fork or the same repo? +- INTEGRATION EVENTS with Event-Bus implementations: Implement Event-Driven communication between microservices/containers based on Event-Bus interfaces and two implementation: + 1. (PRIORITY) Standalone Pub/Subs messaging implementation based on an out-of-proc RabbitMQ Container + 2. (Future version) Azure-attached implementation based on Azure Service Bus using Topics for Pub/Subs +Two integration event scenarios to implement in the app: + 1. Simple (higher priority): Change Product info (name, image URL, etc.) in the Catalog and update that in the existing Orders and Baskets (all, except the price) + 2. Complex: Events propagating Order's states changes related to the Order-Process SAGA (InProcess, Paid, Handling, Shipped, Canceled if timeout because it was not paid, etc.) - Scenario to be discussed/defined + +- Monolithic ASP.NET MVC app with public area of the eShop (Home page with catalog-view functionality, basically). As out of band, separate project (same GitHub repo but separate folder and separate solution) + +- WebForms client (Catalog Manager/Simple CRUD maintenance): In the Windows Containers fork, implement and add a client ASP.NET WebForms application (running as a Windows Container) consuming the same microservices, as an example of "lift and shift" scenario. +SCENARIO: A simple CRUD edit WebForms app for the Catalog, consuming the Catalog microservice to add/update/delete products. As simple as possible.. + - Exception Handling - As an ASP.NET middleware? Middleware from ASP.NET Core with custom implementation which records specific exceptions depending if it is in production. Business-Exceptions + Generic-Exception-Handler (ExceptionHandlerHandler) - Implement "Idempotent" updates at microservices, so the same update (like a Payment or OrderCreation) cannot be executed multiple times. Server must implement operations idempotently. An operation is idempotent if it gets the same result when performed multiple times. Implementing idempotency is domain-specific. -- INTEGRATION EVENTS with Event-Bus implementations: Implement Event-Driven communication between microservices/containers based on Event-Bus interfaces and two implementation: - 1. (PRIORITY) Standalone Pub/Subs messaging implementation based on an out-of-proc RabbitMQ Container - 2. Azure-attached implementation based on Azure Service Bus using Topics for Pub/Subs - -Two integration event scenarios to implement in the app: - 1. Simple (higher priority): Change Product info (name, image URL, etc.) in the Catalog and update that in the existing Orders and Baskets (all, except the price) - 2. Complex: Events propagating Order's states changes related to the Order-Process SAGA (InProcess, Paid, Handling, Shipped, Canceled if timeout because it was not paid, etc.) - Scenario to be discussed/defined +- Resiliency: + 1. Resilient synchronous HTTP communication with retry-loops with circuit-breaker pattern implementations to avoid DDoS initiated from clients (*** This is a priority ***) - Initial implementation with Polly: https://github.com/App-vNext/Polly/ OSS lib. + 2. Gracefully stopping or shutting down microservice instances – Use the new library implemented as an ASP.NET Core middleware, to be provided by the .NET Team (Need to wait for that library) - DOMAIN EVENTS: Implement Domain Events which is related but not the same as integration events for inter-microservice-communication. Domain Events are initially intended to be used within a specific microservice's Domain, as communicating state changes between Aggregates, although they could derive to Integration Events if what happened in a microservice's domain should impact other additional microservices. SCENARIOS TO IMPLEMENT: 1. Check price change basket vs. catalog when converting to Order: https://github.com/dotnet/eShopOnContainers/issues/38 2. Multiple AGGREGATE changes within the same Command-Handler, decoupled by domain events. 3. Might need Domain events related to the SAGA implementation - See discussion: https://blogs.msdn.microsoft.com/cesardelatorre/2017/02/07/domain-events-vs-integration-events-in-domain-driven-design-and-microservices-architectures/ Preferred method: Two-phase Domain events (a la Jimmy Bogard): @@ -39,15 +46,7 @@ We should probably implement Domain Events when implementing the SAGA example pl - Implement a SAGA example of a long running instance of a business process (similar to a workflow but implemented as a class with state persistence). The business process would be the "Order-Process-Saga" workflow, involving multiple mock services like PaymentGateway, StockChecking, etc. while changing the Order's state until the order is shipped. Then a background job which fakes ordre delivery and changes order states to delivered. -- Resiliency: - 1. Resilient synchronous HTTP communication with retry-loops with circuit-breaker pattern implementations to avoid DDoS initiated from clients (*** This is a priority ***) - Initial implementation with Polly: https://github.com/App-vNext/Polly/ OSS lib. - 2. Gracefully stopping or shutting down microservice instances – Use the new library implemented as an ASP.NET Core middleware, to be provided by the .NET Team (Need to wait for that library) - -- Monolithic ASP.NET MVC app with public area of the eShop (Home page with catalog-view functionality, basically). As out of band, separate project (same GitHub repo but separate folder and separate solution) - -- WebForms client (Catalog Manager/Simple CRUD maintenance): In the Windows Containers fork, implement and add a client ASP.NET WebForms application (running as a Windows Container) consuming the same microservices, as an example of "lift and shift" scenario. -SCENARIO: A simple CRUD edit WebForms app for the Catalog, consuming the Catalog microservice to add/update/delete products. As simple as possible.. - +- Resiliency 2: - Use a new Health Check Library (Preview) to be provided by the .NET Team. That library provided by the .NET team will provide: A model of healthcheckresults, A Middleware to return ok/bad, A polling service calling the healthchek service and publishing results (open/pluggable to orchestrators, App Insights, etc.) Our task here will be to use that new lib.