Platform Abstraction Layer

Main > Key Concepts > Platform Abstraction Layer

The most fundamental strategy steering Liquid's design is its responsibility to decouple as much as possible the application components from underlying platform ones.


Liquid concentrates most of platform (technology) specific dependencies in one single point of code thus freeing up the many application (business) components to access pre-integrated, high abstraction primitives for doing their jobs.

Considering that no business software engineering project is commissioned to primarily do such technology integration repetitive tasks, those can be considered marginal costs for such type of project.

Hence an abstraction layer like Liquid diminishes such costs as much as great is the number of business components written on top of it - without having to deal with those low levels details.

Additionally (and even more important), now there are only a handful of dependency points on a given set of technology components (i.e. on their SDKs and APIs).

Regarding the guiding principle of multi-platform components of Liquid, the pretty easy replacement of one specific Liquid cartridge by another allows for avoiding technology lock-in in a controlled and productive way.

See a sample code activating Azure Service Bus as the message bus used for asynchronous communication between microservices:

//Injects the MessageBus cartridge for Azure Service Bus
WorkBench.UseMessageBus<ServiceBus>();

Last, but not least, this lock-in avoidance approach makes it possible to use the best of breed from all vendors, even if their solutions are not market standard yet.

Actually, the corollary of a given market standard is to be a commodity technology.

Accordingly, Liquid helps to transcend the classical trade-off between being open & commodity or being locked-in & differentiated.

Adding new technology platform capabilities to all business application components can be done, once again, from a centralized point, in a controlled and agile way.