Monolith to Microservices - The Modernization Playbook

Explore modernizing a legacy codebase from monolith to modular monolith to microservices, focusing on backend structure, discovery of pain points, and planning slicing with swagger APIs and front-end portal.

Explore the modernization path from a healthcare claims monolith to modular monolith and microservices, starting with understanding legacy backend structure, folder layout, controllers, repositories, and dependency injection.

Explore how the program.cs entry point wires the monolith’s services, EF Core with SQLite, and swagger-enabled APIs, using unit-of-work and repository patterns to prepare for microservices modernization.

Explore healthcare claim models, detailing the data structures for policy, member, provider, claim, and documents, and tracking claim life cycle statuses from draft to paid.

Explore how the claims controller acts as a thin API layer, routing requests to the claims workflow service via dependency injection, with endpoints for get, submit, approve, and reject claims.

Analyze how the monolith's claims flow service coordinates claims, member, policy, provider, document, and notification data with audit and unit-of-work, illustrating modernization through service slices and workflow checks.

Define repository contracts via interfaces and implement them with a unit of work, transaction management, and ef core crud operations, wired through startup.

Explore how the healthcare claims db context in EF Core maps tables with db sets, enforces primary keys like policy number and claim number, and defines owned claim lines.

Seed the application's SQLite database with policies, members, providers, claims, and documents using a static database seeder at startup, ensuring no duplicates and clearing the EF Core change tracker.

Explore the swagger to inspect the legacy API surface, adjust launch settings, and test endpoints like members and payments, capturing a complete snapshot for modernization.

Examine the frontend architecture of a React + Vite health care claims portal, highlighting its strongly typed TypeScript surface and API interactions to inform back-end modernization.

Explore domain discovery as the foundation of a modernization plan, detailing current state assessment, business capabilities, domain events, bounded contexts, context maps, and extraction priorities for the architecture review board.

Learn how to assess a monolith system, map domains and bounded contexts, and plan modernization using domain discovery, current state assessment, and a prioritized mitigation plan.

Identify and map capabilities by grouping models, controllers, and services by responsibilities. Classify core and supporting domains, emphasizing claims processing, ubiquitous language, and domain events for modular monolith and microservices.

Explore domain events and event storming to map business facts from claim submission to payment settlement, and learn how domain and integration events guide monolith to microservices modernization.

Understand bounded contexts in domain-driven design by mapping ownership to business language, defining explicit aggregates and events, and preventing cross-context state updates for monolith to microservices modernization.

Understand the context map as a domain discovery tool that defines bounded contexts—policy, membership, claims, documents, and payments—and shows their collaboration within a modular monolith toward eventual independent deployment.

Assess extraction priorities with a decision matrix balancing business value, coupling, and migration risk. Documents emerge as the first extraction candidate due to clear boundaries and low migration risk.

Explore modular monolith architecture with an api host gateway loading modules like claims, documents, membership, payments, and policy, then extend to microservices by selecting first candidates from domain pain points.

Scaffold a modular monolith by creating a solution, an api host, and a building blocks project with abstractions and interfaces, then assemble them as composition root to expose http endpoints.

Define an IModule contract; let each module register its services and map endpoints in the api host, enabling modular monolith wiring for modules like claims, policy, and membership.

Fix NuGet package references in an ASP.NET Core app, showing how the framework reference handles routing, minimal APIs, and authentication and authorization, and add a modules folder with projects.

Add modular components by creating module projects in the source folder, adding policy, membership, claims, documents, payments, and more to a dotnet solution, then rebuild to verify integration.

Learn to add and wire module references across projects, including building blocks and the abstraction layer, set up the API host and discovery, and verify with a full solution rebuild.

Implement modules step by step—from audit to claims, communications, documents, and membership—by implementing the IModule interface and defining metadata and read-only properties for each module.

Extend a monolith to microservices by adding payments, policy, provider network, and reporting modules, implementing the IModule interface, and defining module metadata and descriptions.

Remove boilerplate program.cs, configure the builder to stitch modules together by adding services and controllers, register nine modules, and map modular endpoints for a modular monolith API.

Demonstrate the modular monolith by loading modules through a common i module contract, exposing metadata, and paving the way for domain model, repository pattern, and application services.

Explore vertical slicing in modernizing a monolith by modularizing the membership, policy, and provider network domains, using a minimal API, in-memory repositories, and swagger for testing.

Explore building policy domain objects within a vertical slice, create a policy DTO with id, policy number, provider, product, and status, and define effective dates and balance.

Define policy domain objects by creating policy plan type as an enum with values like individual, family floater, senior citizen, and corporate group, policy status and a suspended grace period.

Implement an application layer with a policy repository, define a policy summary dto, and manually map insurance policy to policy summary for api responses, converting enums to strings.

Implement a policy application service that exposes list and get by id use cases, depends on IPolicyRepository, maps to policy summaries, and bridges API endpoints with the data layer.

Implement an in-memory policy repository and seed data for a modular monolith, exposing get by id and by policy number via IPolicyRepository, with a real database replacement later.

Implement minimal policy endpoints using points to list policies and fetch by id, with status filtering and swagger tags, wired by a scoped application service and in-memory repository.

Define the membership domain by creating a member status enum and a member entity with key fields, and organize the project into application, domain, endpoints, and infrastructure.

implement a membership mapping module by defining a member repository interface with read-only collections and get by id and list by policy number, plus member summary mapper and application service.

Develop a membership application service that lists members with optional status and policy number filters, returns member summaries, and supports get by ID, paving the way for infrastructure.

Implement an in-memory member repository, seed sample members, map endpoints for list and get by id, and wire this into the membership module with a singleton repository and application service.

Define provider domain objects in a modular monolith, including enums for network tier and status, and a provider record with id, code, name, specialty, city, state, status, and cashless enable.

Implement the application layer for providers by wiring the repository and mapping to a provider summary DTO. Expose filters for city, speciality, cashless, and network tier, plus get by id.

Implement an in memory provider repository with seed data, expose endpoints to fetch by code or id and filter by city, speciality, cashless enabled, and provider network.

Add swagger in api host with swashbuckle.aspnetcore, enable api explorer, and implement a string enum schema mapper in program.cs to produce open api docs and swagger ui in development.

Update Swagger to version 10 and add http methods for members, policies, and providers, verify build success, and explore module testing within the Swagger UI.

Explore how to modularize data exchange in a claims module by using reference data and avoiding direct module-to-module calls, enabling endpoint-driven communication with policy, provider network, and members.

Build the claims domain structure for a modernization playbook by creating domain folders, a claim line model, and enums for status and type.

Define the claim aggregate with read-only properties and a constructor to initialize required fields, then implement lifecycle methods like mark under review, approve, and reject, enforcing status rules.

Design and implement the claim repository in the application layer, expose read-only collection of claims, provide list, get by id, and add methods, and map claim summary and claim detail.

Construct a claim summary mapping from a claim domain, extracting id, claim number, policy number, member number, provider code, type, status, total and approved amounts, and date fields for audits.

Create a claim details mapping and implement a static mapper to convert a claim into a details object with id, claim number, policy number, member number, and date of service.

Create submit claim request and claim decision request records with domain objects and mappings, and build the application service to enable over the wire data exchange for modernization.

Create reference data in the building blocks to support cross‑module eligibility checks for claim validation, via public contracts for member, policy, and provider network eligibility.

Implement the member eligibility reader in the membership module by locating a member by number and returning a member eligibility object with number, full name, policy number, and status.

Implement a policy eligibility reader with a policy repository to fetch by policy number, check active status, balance, grace period, and return effective dates.

Implement provider network eligibility by adding a reader class, wiring the repository, and returning provider code, name, network tier, and status for claim creation.

Implement the claim application service with dependencies (claim repository, policy eligibility reader, member and network readers, providers), exposing a read-only claim summary list and a get-by-id claim details method.

Implement the claim application service with validation, construct a new claim from policy, member, provider, diagnosis, and line items, mark under review, and return claim details.

Implement an in-memory claim repository with a thread-safe sync root, supporting add, get by id, and list operations along with seed data, to enable modular adapters for any database.

Implement claims endpoints with minimal APIs, including list, get by id, and submit claim routes, plus error handling and standard responses like ok, not found, and bad request.

Implement the claims endpoint with under review, approve, and reject flows. Tie in the claim application service and caching for reliable responses.

Register the claims module components and in-memory claim repository, and register the claim service. Map endpoints, extend program.cs with string enum schemas for claim status and type, and test build.

Learn how to validate swagger endpoints for claims by registering scoped services, implementing eligibility readers, and testing get and post requests against in-memory data.

Support monolith to microservices modernization by applying serializer options to convert enums, validating http endpoints, and wiring the claims module to other modules via building blocks.

Identify microservices candidates while implementing documents and payments with a modular monolith and vertical slice architecture, connecting building blocks across claims, documents, and payments.

Modularize the documentation and payments module by implementing a claim reference reader contract to validate claim existence and approved amount, defining a claim reference and a get-by-claim-number method.

Implement a claim reference reader to fetch a claim by number and return key fields: id, claim number, policy number, member number, provider code, status, total and approved amounts.

Design a mutable claim document domain object with enum document types and statuses, implementing verify and reject lifecycle methods, and organize code into application, domain, and infrastructure layers for modernization.

Implement the application layer by defining the claim document repository contract and records such as register claim document request and document decision request, and establish mapping for processing.

Create a claim document summary mapping and a mapping layer that exposes fields like id, claim number, document type, file name, storage reference, status, notes for document application service.

Implement a document application service to manage claim documents, including listing and retrieval by id. Support verify and reject workflows with validations for claim number, file name, and storage reference.

Implement an in-memory claim document repository that lists, retrieves by id, and adds documents, using a synchronization lock and an exclusive log to ensure safe concurrent access.

Explore implementing document endpoints within the module by wiring singleton services, an in-memory document repository, and mapping endpoints for listing, getting by ID, creating, verifying, and rejecting documents.

Build a payment domain with payment status enum and payment instruction object, including id, payment number, claim number, name, bank account, IFSC code, amount, status, scheduled date, and remarks.

Explore designing the application layer by defining DTOs and requests, including scheduled payment request, payment remarks request, and create payment instruction request, and implement the mapping object.

Create the payment instruction summary mapping class and implement from payment instruction to capture id, payment number, claim number, name, account, ifsc, amount, status, and remarks; run a quick build.

Build a payment instruction repository interface and implement its methods: list, get by id, get by claim number, and add, and then develop the main application service implementation.

Create a payment application service that validates approved claims and amounts, enforces guardrails, and supports creating, retrieving by ID or claim number, and scheduling, settling, or marking payments as failed.

Implement an in-memory payment instruction repository that fulfills the payment instruction repository interface, uses a thread-safe lock, and provides get by claim number, get by id, and mock data.

Create and connect the payment endpoints and module, including post create payment instruction, scheduler, settle flows, map types, and program registration with an in-memory repository and payment application service.

Run and explore the Swagger demo to verify API endpoints for claims, documents, payments, and modules, send requests, and validate responses like 201 created and 400 bad request.

Fix the claim number by ensuring proper claims approval before payments, demonstrate api http endpoint testing and end-to-end integration testing for claim workflows.

Explore the pub/sub event broker in a modular monolith to decouple publishers and subscribers, enabling scalable handling of claims, documents, and payments with audit and notification support.

Explore how an in-process event bus enables cross-cutting event publishing and subscribing across modules, using integration events, event handlers, and a decoupled architecture.

Create and implement business events such as claim approved, claim rejected, claim submitted, document verified, and payment settled as integration events with defined fields.

Implement the audit side by creating application, domain, infrastructure, and endpoints folders, and define an audit entry dto record with id, module, event name, entity reference, summary, and occurred on.

Create an audit entry repository by defining the public interface for audit entries, adding a summary mapper, and exposing methods to map audit entries to summaries for application use.

Create an audit event handler that records integration events such as claim submitted, claim approved, claim rejected, document verified, and payment settled using an audit repository and audit entries.

Implement an audit application service that queries the audit entry repository, filters by module and event name, orders by occurred on descending, and converts entries into audit entry summaries.

Implement an in-memory audit entry repository by creating a sealed class that implements audit entry repository interface, using a thread-safe list and a sync root to return entries as array.

Create and expose audit endpoints under /api/audit, register the audit module, wire in the audit repository, application service, and event handlers for claim, document, and payment events.

Create notification status and channel enums and model a notification message record with recipient, channel, subject, body, source event, status, and created on; then begin the application layer.

Implement a notification repository interface, define a notification summary record, and build a mapper to convert a notification message into a DTO with id, recipient, channel, subject, body, source event.

Implement a notification event handler in the application layer, wiring integration events for claim submitted, claim approved, claim rejected, document verified, and payment settled, persisting notifications via the repository.

Create a notification application service that uses a notification repository to build and execute queries. Filter by recipient and source event, order by created on, and return notification summaries.

Implement an in-memory notification repository, with a sync root and read-only list, and wire up services to provide a singleton INotificationRepository, a scoped notification application service, and the /api/Notifications endpoint.

Wire up the claim application service to publish claim events via an event bus, emitting submitted, approved, and rejected events with claim, policy, and member details for downstream subscribers.

Publish claim and document events via an in-process event bus to decouple modules, with audit and notification handlers reacting to claim submitted, document verified, and payment settled events.

Wire up an in‑process event bus and notification channel, update endpoints, and validate audit and swagger flows to test claim submissions and ensure correct event ordering.

Fix event ordering in a microservices workflow by validating claim submission, approval, document verification, and payment settlement through decoupled publish-subscribe events and in-memory processing.

Wire the reporting module to the frontend dashboard, subscribe the event handler to business facts from claims and payments, and implement the reporting api with claim and payment summaries.

Build a cross-module, read-only reporting model that listens to events like claim submitted, approved, rejected, document verified, and payment settled, providing auto predictions for dashboards and operational queries via endpoints.

Define and implement the application layer for payment reporting by creating interfaces, projections, and DTOs, including claim, operational, and payment summary reports.

Builds a pluralized reporting application service and event handler to supply operations, claim, and payment summaries and a dashboard view. Subscribes to events and handles recent events for comprehensive reporting.

Implement a thread-safe in-memory reporting projection repository and expose reporting endpoints to deliver operations, claims, and payments summaries as minimal APIs.

Implement the reporting module by wiring the singleton reporting model to an in-memory projection repository, register integration event handlers (claim submitted, approved, rejected, document verified, payment settled), and map endpoints.

Demonstrate a React frontend in TypeScript for a modular monolith. Run npm run dev modular, proxy to the backend, and explore the claims dashboard with submission and audit trail.

Explore building a triangular gateway from scratch that sits in front of a modular monolith, routing front-end requests to documents and services, with future microservices extraction and a forward proxy.

Create and attach a gateway project to a new .NET solution via the command line, then configure appsettings.json and program.cs for integration with the existing solution.

Implement a strangler gateway to insulate the frontend from a modular monolith, establishing a stable gateway-driven API and routing plan for future microservice extraction.

Create a typed strangler configuration for gateway routes by defining a strangler root, gateway options, and destination URLs, then map roots to proxy objects for secure data routing.

Create a proxy gateway that forwards requests using a configured route, defining HTTP methods and a strangler route selector to pick the most specific path prefix for incoming requests.

Create a gateway proxy as the reverse proxy for the strangler gateway, forwarding requests to the destination and returning responses. Build the destination URI and configure logging.

Create a gateway proxy for monolith-to-microservices modernization, building the destination uri, forward method, and streaming upstream responses with diagnostic headers.

Create an ASP.NET core gateway endpoint mapping extension for a strangler gateway to expose HTTP routes and forward API traffic to the owning back-end.

Learn to build a gateway endpoint in a classic ASP.NET Core proxy, fix configuration duplication, and implement health checks that report upstream reachability, status, and exception details.

Configure a new web app by creating a builder, configuring gateway options, wiring the http client and strangler gateway proxy, and mapping front-end course endpoints.

Learn frontend changes that connect to the strangler gateway on port 5230, update gateway configuration, and run the dev gateway with npm scripts.

Explore how a strangler gateway routes a modular monolith API, enabling testing of endpoints, creating and approving claims, and wiring front-end capabilities toward a microservices modernization journey.