API-led connectivity and CQRS: How Mule supports traditional integration tasks

API led connectivity

There is a lot of interest in how Mule supports emerging patterns like CQRS (Command Query Responsibility Segregation), so I wanted to create a series of blog posts discussing an insightful approach. Over the course of the series so far, we described the initial problem at hand and how to solve it using CQRS and API-led Connectivity. Next, we designed and implemented the synchronous Query API application followed by the implementation of the asynchronous Command API application with a composable API architecture.

API-led Connectivity and CQRS: API layering and the CQRS API implementation

In this 4 part blog series, I describe in detail how one might go about modernizing a functional, but legacy Supplier Relationship Management (SRM) application without redeveloping (or even touching) it. Why? The release cycle for the legacy app is too long and it doesn’t scale in a way that will meet the needs of newly required mobile application.

Additionally, an aspect of SOLID software design is the Open/Closed Principle which in our case can be applied as we are extending and providing functionality without actually modifying the core application.

API-led Connectivity and CQRS: The Challenge

motif

Part 1: The Challenge

Let’s imagine you’ve been working as an architect in a large company for several years and are very proud of the now mature Supplier Relationship Management (SRM) application you specified, formed, and delivered to the business, as it continues to provide value.

Functionally, the SRM is a web application that allows for managing relationships of suppliers and materials, maintaining hierarchical structures, uncovering unwanted dependencies and helping your clients significantly reduce supplier costs.