Understand business logic to fortify microservices design
Before software teams introduce microservices, they must take a critical look at the business logic that frames their architecture because, as contexts change, so does the logic.
All software must meet the needs of the target users it serves. Those needs are often referred to as the business needs of an application. At the design stage, those needs are translated into business logic. However, one of the most fundamental challenges of software design is to transform business logic into an application architecture that meets those business needs completely.
Because microservices architecture is designed as an orbit of individual services, it is capable of faithfully reproducing an application's business logic in a way that meets high functionality and performance standards, and it's easy to maintain and update.
From business logic to microservices
But how can you ensure that your application architecture at the microservices design level actually reflects the business logic? While there are no strictly mechanical or algorithmic formulas that translate business logic into microservices, there are some commonsense application development guidelines that help microservices -- both individually and in terms of overall architecture -- correspond closely to an application's business needs and business logic.
Understand your business needs
Microservices design planning should start when business needs are translated into business logic. If the business logic fails to reflect real-world business needs and use cases -- for instance, by neglecting to take into account all of the sources of demand for specific services or the volume of the demand placed on those services -- then you run the risk of building bottlenecks and other performance issues into your software at the architecture level. If your business logic misses key relationships between services, it can affect the overall architecture and design of individual microservices. This oversight can result in spaghettilike patches or the need for an extensive redesign.
Decomposition and architecture
The pattern you use to decompose a monolithic application into microservices is often as important as the business logic itself. For example, if you initially decompose a monolithic application into large-scale blocks of services -- such as sales, inventory, ordering and billing -- then the resulting set of microservices may look significantly different from ones produced from a decomposition pattern that focuses on lower-level services or a strict use case model.
Know how to break it down
It's important to know which decomposition pattern or combination of patterns you will use. It's also important to understand the relationship between that pattern and the application's business logic. It's entirely possible that one pattern will correspond closely to some parts of your business logic and not to other parts. If this is the case, it is probably better to apply different decomposition patterns where appropriate rather than try to shoehorn the entire application into one pattern. When you apply different decomposition patterns, the ensuing microservices and their relationships are likely to reflect the differences in those patterns.
What should and shouldn't be a microservice
You need to understand what does and does not qualify as a microservice within the context of your application's business logic and decomposition pattern.
You need to understand what does and does not qualify as a microservice within the context of your application's business logic and decomposition pattern. The key word here is context. Some operations, like communication with peripheral devices or data transfers to third-party services, are almost always good candidates for microservices. But depending on the situation, those operations may either work best as individual services or as a collection of smaller services.
For example, one application may require just one generic microservice for database reading and writing, while another might need individual microservices that handle specific types of records. Meanwhile, another application may require individual microservices that handle different types of data formats.
Know where you are, know where you're going
If there is an underlying principle to these guidelines, it's this: Before you to turn business logic into microservices, you must completely understand your application's business logic, from its overall structure down to specific operations and relationships. This information guides all other aspects of the process.
There are many more factors to consider, of course, in terms of both business logic and microservices design planning, but it's crucial to understand and negotiate the interface between business logic and microservices architecture in order to create applications that provide the functionality, performance and quality of service your users need.
Dig Deeper on Application management tools and practices
