A Business Rules Management System (BRMS) is a perfect complement to a Microservices Architecture. The reasons for implementing a BRMS are even more compelling in a Microservices Architecture.
In this blog, I will discuss the reasons for using a Business Rules Management System (BRMS) in a Microservices Architecture and then explore a use case to demonstrate these benefits.
Microservices Architecture is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms called an API. These services are built around business capabilities and independently deployable by fully automated continuous integration/continuous delivery (CI/CD) pipelines.
The following diagram illustrates the difference between a traditional Monolith Application and an Application using a Microservices Architecture.
- Software built as microservices can be broken down into multiple component services. These services can be deployed and redeployed without compromising the integrity of the entire application.
- Services can be independently scaled.
- If one microservice fails, the others will continue to work.
- Code for different services can be written in different languages.
- Services are easier to modify and understand. New team members can become productive more quickly.
- Increased autonomy of individual development teams within an organization. Ideas can be implemented and deployed without having to coordinate with a wider IT delivery function.
- A repository, allowing decision logic to be externalized from core application code
- Tools, allowing both technical developers and business experts to define and manage decision logic
- A runtime environment, allowing applications to invoke decision logic managed within the BRMS and execute it using a business rules engine
- Externalize rules from application code
- Write rules in domain language
- Test rules independently from application code
- Make consistent and efficient decisions
- Quickly build resource optimization solutions
- Shorten development cycles for faster time to market
- Empower business experts to manage change directly
- Reduce or remove reliance on IT departments for changes in live systems. Note that QA and Rules testing will still be needed in any enterprise system.
- Increased control over implemented decision logic for compliance and better business management
- Ability to express decision logic with increased precision, using a business vocabulary syntax and graphical rule representations (decision tables, trees, scorecards, and flows)
- Improved efficiency of processes through increased decision automation
Bringing the Two Together
In a Microservices
Business Rules Management Systems in a Microservice Architecture Use Case
To demonstrate Business Rules in a Microservice
The following diagram illustrates the components of the FHIR Medical Repository Microservice Application.
The Architecture to implement the FHIR Medical Repository Microservices Architecture Application includes the following:
- SpringBoot - FHIR Microservices
- Red Hat JBoss Business Rules Management System (BRMS) - The Business Rules Management System
- Docker - Package Microservices for Deployment
- OpenShift - Platform as a Service for Orchestrating deployments of
- Jenkins - Perform CI/CD pipelines
- Git - Source Code Repository
The code for the FHIR
You can check out one of our recent webinars, viewable on-demand, detailing the FHIR Medical Repository Microservice Architecture Application here. The source code for the Microservices is located at https://github.com/Vizuri/openshift-fhir-rules-microservices. The source code for the business rules is located at https://github.com/Vizuri/openshift-fhir-rules-rules.
If you'd like additional information, or to schedule a complimentary consultation please don't hesitate to contact us.