English | EN 
Loosely coupling applications and modules is a well-known architecture pattern, at least on paper. Realisation is sometimes more complex in real life, as some interactions are highly coupled. In parallel, micro-services architectures become common practice: this article is about seizing this opportunity to better decouple services and linearise costs.
Focusing on web applications and associated back-end services, what we often see today are applications that become increasingly complex due to “context management”. Apps, especially those from the new economy, have multiple actors, who can do different things. They also manipulate different concepts and entities. And the intersection between those two worlds (Who and What) is not static anymore. Objects or entities, however, we want to call them, have a complex lifecycle that interacts with the user population.
Let’s take the example of corporate internet banking. In the corporate world, operations must be validated according to the four-eyes principles. The employee who creates a wire transfer is not the same person as the one who will validate this transfer. We should also take consider that a user might not validate his own transfers. From the object model standpoint, we are in all cases dealing with the same object or entity, which is just in a different state, a different context. Extend this principle to most banking operations and you start scratching your head.
Let’s take another example: a recruitment website (such platforms are today numerous, for example for hiring freelancers). The mission entity or object is shared between recruiters and freelancers, but not everybody can update the same information at the same moment.
Most apps today share this contextual problem, and this is a serious reason behind an exponential development cost curve. The combination of situations tightly couples the business rules, bringing exponential complexity to the back-end services powering the app.
However, a simple solution can be deployed to simplify the architecture by decoupling business rules. Let’s take back the internet banking example. A “maker” creates a wire transfer request. This request is managed by a stateful service whose job is simply to manage the context, this service manages the stateful, long-lived information: let’s call it the contextual service. No need for managing complex transfer controls here: the second layer of stateless services will do that. Finally, when it is time to push the transfer to the core banking system, the contextual service is consuming a couple of other stateless services:
- The first service checks if the transfer is doable (this service can also be called at transfer creation, even before it is validated)
- The second one pushes the transfer to the core banking
Following the same strategy, a collection of stateless services will be developed (or methods of the same service, as it is no more than a deployment granularity choice), managing individual business rules. Their stateless characteristic is key for de-coupling.
The contextual service is the one having relationships with the stateless layer. Repeating this pattern for the various entities or entity groups of the App leads to a contained number of services that manage coupling. Those services are by nature part of the “adaptive layer” required for any web application. Managing context is their sole responsibility.
Such services may be realised using various orchestration technologies or even by hand in a classic app server. Separating business rules and behaviour/context management is what avoids hitting the exponential cost curve. Context management is likely to be changed many times during an Agile project, unlike the business rules which usually have a longer lifecycle. Stateless “rules” services can be very easily maintained by team members that may just focus on the rule itself.
Although this approach doesn’t pretend to solve all problems nor is it an absolute rule, it’s leveraging with good results the “stateful+stateless” service layers combination and available technologies such as cloud functions. Using stateless services is an indirect way to force decoupling and make sure it is not just on paper.
Team organisation benefits from this decoupling between business rules and context, with better-defined responsibilities and clear, simple mandates given to developers. As often with architecture patterns, the human factor is key.
