Microservices: using resources and business services as extensibility strategy

In this post, I want to share with you a strategy intended to improve your system’s extensibility — in other words, making your business better able to cope with future change. Of course, not everyone sees the world with the same eyes, so if you disagree with something, please share your thoughts — it will be appreciated.

Before we begin, I want to share a use case, that should make it easier to frame the concepts and the problems this article will explore.

So, we’re going to explore a fictitious start-up, that I’ll call WidgetKing. As it grows, its executives realize they need a system for managing its employee annual leave. This company decides to create a leave app that will have the employee and leave data.

Figure 1: Initial architecture

The initial architecture enables the development team to deliver rapidly.  But, over time, other applications want to consume the leave information to generate reports, dashboards and populate BI systems.

After some time thinking about those requirements, the team decides to expose the leave endpoints as an API that will be consumed by other apps and extract the leave management logic to a separate app.

Figure 2: Extracted Leave API

Now, the architecture is able to expose the leave information to other services.

After more time, WidgetKing wants to create a new service that manages all employee benefits, including medical care, transport subsidies or insurance.

To build this new app, the team will need to use the employee data, and following the same concept of the leave API, they decide to extract the employee data from leave API to a new service. This approach avoids spreading the employee business logic through the system.

Figure 3: Employee resource service extracted

Now, they have clean services with a single purpose and responsibility. And it is a Resource Service.

A Resource Service is responsible for only storing and managing its own information. It doesn’t mean that you can have to stop storing supplementary data, such as leave type, but, you should be careful about the type of information that you save in this kind of service. As a rule of thumb, you should keep the minimum data possible for the service to work it to work.

Using resource services to extensibility

Now, WidgetKing expands to other countries and the employee service doesn’t support the level of data legally required in the new countries. Without this information, the company cannot generate benefits contracts and other important stuff like employee payments.

So, to resolve this situation, the tech team comes up with two options. The first is to put all those fields into the model. The second one is to create a service that will wrap up the business logic from each country.

This first option will generate a big fat model, and mean that any future change — for instance when a country wants to add some new information — it’ll increase the logic complexity. Option two will allow WidgetKing to handle different business contexts with its own specific business logic and doesn’t create a new monolithic service. It also decreases the need for changes in the common resource. Other positives are scalability and maintenance.

So the second option seems the best choice, which is how WidgetKing proceeds.

Figure 4: Architecture with business services

The new services extend the Resource Services to provide some additional functionality or information, without changing the core resource. We call these additional services Business Services or Capability Services.

The objective of a Business Service is to provide a new capability for an existent resource or additional information that is not common to other services.

So, using these patterns, we can create a platform ecosystem that provides to you and your company a fast way to develop and validate new ideas removing friction and avoiding repeated and inconsistency business logic between services.