EWF Service Decomposition Pattern

EWF is another microservice decomposition pattern that I like to use when building services. It stands for Entity, Workflow & Functional services. In simplest terms, it’s an extension of Single Responsibility principle and allows for building independent testable services. To understand this pattern better, let’s start with an example. Imagine I want to write a signup service that allows user to signup to a website using their Google account. The service would perform the following: 
  • Let user login into google account and fetch user’s basic information from Google upon successful sign-in.
  • Apply more default settings associated to creating new user. 
  • Persist the user in the database. 
  • After successful registration, redirect the user to the homepage. 


At a high level, this works just fine and gets the job done. But if you think about testability first and wants to test this service in isolation we have a problem! The entire testing paradigm relies on the fact that the OUTPUT should have a direct correlation with the input. In this case the input is a signup request but output produced is a redirect response. There is simply no way to test this service in isolation. i.e I cannot test if the defaults are applied correctly or if the user is persisted correctly in the DB using the service api tests. One could use unit tests to test these individual functionality but in microservice architecture, a service is an unit in itself exposed as apis, we should be able to test them in isolation. More thoughts on this topic here and here. Read more about how to test service in isolation here.

Let’s try to apply EWF decomposition pattern by identifying the different parts:

Entity: User is clearly the entity here. We will need to Get/Save/Delete user from the DB. Entity service should only worry about saving and retrieving User from the storage and should avoid any funny business logic. This would allow me to keep the separation b/w business logic and entity and making sure this service is only concerned with persistence and exposing it over API to keep the loose coupling wrt rest of the stack.

Functional: We need to identify the functional parts in this workflow that can be performed w/o mutating the state of the system. In this case, fetching user information from google and apply more default settings to create a domain but non-persisted user object. This is arguably the most important business need of this workflow. Encapsulating this piece in a service would allow me to test if defaults are applied correctly in isolation and w/o having to worry about persistence.

Workflow: This would bootstrap the entire workflow: 1)Create the non-persisted domain user object by calling the Functional service API 2)Persist the user by calling the User Entity service 3)Redirect to homepage. This would allow me to test the workflow w/o having to worry about actually creating the entities or rely on integrations tests to test the workflow.




The benefits of decomposing Entity, Workflow and Functional services other than the obvious benefits of decomposition are:
  1. Entity services provides better encapsulation over the domain model by creating loose coupling and only access through APIs. Extracting out creation of complex domain entity from its persistent allows for better testability. 
  2. Functional service carry the heavy business logic and are highly testable. These services ideally should not be mutating any state in the system. This makes  them perfect candidate for DarkLaunches in the production w/o having to worry about the impact on the overall system.
  3. Workflow services allows ability to test workflows at the component level tests rather than relying too much on the integration tests.
Personally, i feel very confident that the overall workflow will work in production when the individual participating services have been designed for testability and tested thoroughly in isolation. 

Popular posts from this blog

Break functional and orchestration responsibilities for better testability

Image
Microservice architecture paradigm fits well within the Unix’s first principle/philosophy: “Make one program do one thing well”.  We love creating small services which has identity of its own (within a bounded context). These services have their own CI/CD pipelines and provides loose coupling b/w components which significantly improves our ability to deliver code to production. In reality, a workflow can span multiple services. Its very common to find scenarios like below: In the above example, a workflow spans 3 services (Service-1, 2 and 3). Service1 receives the original request. In order to process this request, it GET(s) some data from its dependent services(d1/d2/d3). It further runs some business logic and produces an intermediate response #A. It then makes a state mutable call (POST/PUT/DELETE/PATCH) to Service-B using #A as input and waits for its response. Service-B follows the same paradigm and the workflow ends when all services returns.  The scena...
Read more

Microservices and Tech Stack - Lessons Learned

Image
In this blog, I want to talk about how our technology stack has evolved over time while transitioning from Enterprise to adopting Microservice architecture as a main stream development practice and share some of the lessons learned. Tech stack for us has evolved from being a Monolithic Enterprise to Cloud to now Microservices. During Enterprise days, it looked something liked this: At the app layer, we had a desktop client written in Windows form and WPF. The app would talk to the Service Layer which was SOA architecture written completely in C#. It was the only language allowed for us to use. These were monolithic and stateful services communicating to each other over WCF. We used SQL server as backend storage. All this get deployed on premise meaning our clients buy our software and host it on their own hardware. I work for Finance industry (Stock Market to be precise) and they were sort of late adopter of public cloud. They absolutely hated the idea of putting their data on p...
Read more

Prefer Consumer over Integration Tests

Image
Recently I attended an RCA meeting for an incident that happened in prod few weeks back. The issue was somewhat of a 2nd degree failure. To put it in simple terms, lets say a workflow composed of two services - A and B. When user performed an action from the UI, it made a call to Service A which then internally called service B with some parameters based on user preferences. In this case, due to some unusual combination of preferences, Service-A ended making call to Service-B with parameters that Service-B didn’t fully understood. Solution - Write an integration test to cover this scenario. Reasoning - Since this involved 3 different components (User Preferences, Service A and Service B), it should be covered by an integration test. More Reasoning: This is sort of the usual way of thinking about the integration tests - meaning whenever there are multiple services involved, we immediately think about writing an integration test. But is this the right approach specially in microserv...
Read more