Beyond Read Stores: Handling Commands and Events in Mature Domain APIs

Introduction:

Domain APIs play a critical role in integration, offering a single point of aggregation for a common view of queries, commands, and events. Domain API implementations can often be poor especially when they are pass-through with no domain logic or just providing pure “read stores”. In this post we talk about how to amplify the capability of your Domain APIs to do Commands and Events and going beyond mere read-stores and proxy APIs

This blog post also delves into the pivotal role Domain APIs play in achieving coexistence among disparate systems and ensuring seamless lifecycle management. We use an insurance industry example with a sample Policy API

1. Operational Data Store Pattern for Query:

The Operational Data Store (ODS) pattern is central to providing a consolidated view for queries. It acts as a data hub, aggregating information from various systems into a common format that can be easily accessed and queried by consumer applications. This pattern is especially useful when dealing with multiple legacy systems and ensures that the data remains consistent and up-to-date across all consumer touchpoints.

• Consumer App: Issues a query request.
• Domain API: Interprets the request and retrieves data from the ODS in a common format.
• Read Store (Data Hub): The central repository where data is stored in new and old formats.
• Translator: Converts data between different formats as needed for consistency.

2. Commands Direct to System of Record:

When it comes to performing actions, such as updating a policy or processing a payment, commands are routed directly to the relevant system of record. This ensures that the system which owns the data executes the command, maintaining data integrity and system responsibilities clear.

• Consumer App: Sends a command in a common format.
• Domain API: The API layer that handles the command, determining where to route it.
• System of Record: Executes the command, whether it’s the old system or the new system.

3. Events via Webhook (Push):

Webhooks provide a real-time, push-based pattern to handle events. When a state change occurs within a system, it can instantly notify other systems or consumer applications through a webhook, allowing them to react promptly.

• Consumer App: Configures a webhook to listen for events.
• Domain API: Pushes events to the webhook as they occur.
• Internal Systems: Generate events in either new or old formats that are then pushed out.

4. Events via Events Platform (Pull):

An events platform allows consumer applications to pull events as they occur within the domain. This pattern decouples the event producer from the consumer, allowing for more flexibility and scalability.

• Consumer App: Subscribes to events from an external platform.
• Domain API: Writes events to the events platform.
• Internal Events: Generated by old and new systems, collected by the domain API.

The ‘north-south’ integration axis represents the user interface’s direct interactions with the underlying core systems via domain APIs. Here’s how domain APIs streamline specific customer actions:

Applying patterns

Lets now see these patterns in action for digital channels (north-south) and internal systems (east-west) integrations. We will apply these to specific industry use cases, in our post we will pick insurance and explore this domain in detail

Patterns for North-South Use Cases (Digital channels to Domain APIs)

• Quote Aggregation: The API compiles data from underwriting, product, and pricing systems to provide accurate quotes.
• Policy Issuance: Upon quote acceptance, the API initiates policy creation, pulling data from customer profiles and risk assessment modules.
• Claim Submission: Customers can report incidents and submit claims, triggering the API to gather incident details, policy coverage, and initiate the claims process.
• Billing and Payment: The API orchestrates billing schedules and processes payments by integrating with financial systems and payment gateways.

Patterns for East-West Integration (System-to-System):

‘East-west’ integration is about the communication between disparate domain systems to maintain a coherent operational ecosystem.

• Command Routing: For a policy update, the API routes requests to the specific policy administration system responsible for the type of policy product in question.
• Event Harmonization: When a claim is processed, the API translates various system events into a common domain event format, notifying all relevant systems of the update.
• Data Synchronization: In the case of customer data updates, the API ensures all changes are consistently reflected across every system, such as contact details or beneficiary changes.

Lifecycle Impact:

Domain APIs not only support day-to-day operations but also underpin the entire insurance product lifecycle:

• During Onboarding: They enable a frictionless onboarding experience by connecting digital channels with background check systems, regulatory databases, and initial policy setup services.
• Throughout Policy Management: APIs provide endpoints for ongoing policy adjustments, endorsements, and renewals, communicating with document management systems for record-keeping.
• In Claim Servicing: They facilitate end-to-end claim processing by interfacing with assessment tools, repair vendor systems, and disbursement services for settlements.

Conclusion:

Domain APIs in insurance act as the nexus point for data operations, commands, and event handling, streamlining the coexistence of legacy and modern systems. These patterns—operational data store for queries, direct commands, and webhook and events platform for events—each play a distinct role in modernizing insurance ecosystems. They not only improve operational efficiency but also enhance the overall customer experience by providing more responsive and integrated services.

As we continue to delve into the specifics of domain APIs, it’s clear that their strategic implementation is a cornerstone for successful digital transformation in the insurance sector. For insurance companies looking to adopt these patterns, a discussion with an API architecture expert can pave the way for a smooth transition and future-proof operations.