API-led Paradigms: System Driven vs. Domain Driven Architecture
Uncover the nuances of API-led architecture in our guide. Explore API-led paradigms, system-driven vs. domain-driven approaches, and gain insights from real-world examples.
Introduction
If you're an Enterprise Architect, System Architect, or Software Engineer starting on API-led architecture design, you'll quickly realise that many of the API-led examples found online might not align with your requirements. A substantial portion of these examples simplifies the API-led approach and often falls short in real-world project implementations.
In this blog post, I will delve into crucial considerations for kickstarting your architecture design with API-led methodologies. Moreover, I will provide you with a variety of real-world examples that can be directly applied, empowering you to navigate this complex landscape with confidence.
Problem Statement
If you've delved into API-Led architecture discussions, you've probably encountered one of the most used API-led examples in the internet:
This architecture revolves around the three common layers:
Experience: Customized for organizational channels, primarily mobile and web.
Process: Orchestrating data aggregation and business logic across domains.
System: One dedicated API for each external systems.
However, as you explore this framework, you might find yourself asking:
What if there are no mobile or web apps that consume these APIs?
Will creating a Process API for each domain strain my vCore / Cores?
Can multiple external systems be effectively aggregated into a single System API?
In this blog post, we're here to provide answers. We'll clarify API-Led architecture concepts, answer common questions, and guide you through challenges.
Solution
Balancing Segregation and Aggregation of APIs
Before we dive into distinct API-led architectures, it's crucial to understand the reasons behind segregating or aggregating APIs. Refer to the diagram below for two contrasting paradigms.
The diagram illustrates two models: Segregation and Aggregation. Segregation involves splitting one System API into multiple APIs for different sub-systems. Aggregation consolidates multiple sub-systems into a single System API.
Segregation vs. Aggregation
SEGREGATION:
Flexibility: Each domain evolves independently.
Scalability: Scale each API based on its demand.
Maintenance: Easier domain-specific maintenance.
Performance: Optimize performance per domain.
Complexity: More APIs but granular control.
Granularity: Detailed control over access and usage.
AGGREGATION:
Flexibility: Unified endpoint simplifies interaction.
Scalability: Uniform scaling across domains.
Maintenance: Centralized but might complicate specifics.
Performance: Potential for single point of failure.
Complexity: Fewer APIs, potentially more complex design.
Granularity: General control over domains.
Aggregated APIs and impacts on API Autodiscovery / API Manager
One misconception revolves around API Autodiscovery for MuleSoft applications. Even when multiple System APIs are aggregated, you can configure multiple API Autodiscovery instances within a single Mule application to enable different API policies.
The visual highlights the possibility of having multiple API Autodiscovery configurations within a single MuleSoft application, allowing the application to apply different policies to different endpoints.
System-Driven vs. Domain-Driven Architecture
Armed with insights into API segregation, aggregation, and API management, let's delve into two distinct design approaches.
System Driven Architecture
In the System-Driven approach, each external system corresponds to an Experience or System API. MuleSoft's professional services endorse this approach, leaving Process APIs mostly untouched. Notable aspects include:
Loosely coupled services
Granular deployment options
One connection configurations per application
Reduced merge conflicts due to segregation
Domain experts ownership potential
Domain Driven Architecture
In Domain-Driven design, Domain Experience APIs house related data entities such as:
Customer Experience API: Accounts, Profiles, Opportunities, etc.
Procurement Experience API: Orders, Logistics, Delivery, etc.
System APIs also aggregate into domains, like the CRM System API connecting SAP and Salesforce. Key observations are:
Multiple connection configurations across APIs can lead to operation challenges
Optimal core consumption through aggregation
Increased merge conflicts
Limited granular deployment options
Conclusion
While both architectural approaches offer merits, selecting the ideal strategy hinges on multifaceted considerations. An effective approach might be the combination from both paradigms for optimal results.
The visual demonstrates a hybrid approach integrating System and Domain Driven Architecture. On the System Layer, distinct System APIs exist for external systems. An aggregation bridges Salesforce Core and Salesforce Marketing Cloud, optimizing core utilization and connection configuration overhead.
On the Experience Layer, aggregation within domains ensures elegant REST API resource exposure and distinct policy application via multiple Autodiscovery configurations.
Join the Conversation
We've dissected the paradigms, explored their nuances, and unveiled integration strategies. What's your take on these approaches? Share your insights and queries in the comments; let's spark a vibrant discussion.
References
Check out the first blog post to learn about the API-Led principles and what's permitted and what's not.
What’s next?
API-led for Asynchronous / Event Driven Integrations
API-led for Synchronous Real-Time Integrations
API-led for Batch Processing
Subscribe to stay up to date!