The delivery mechanism is the part of our application that our clients use to execute a platform/application functionality, but it’s not the part that should define the application logic, the business logic ideally should be defined in another layer isolated from External Systems APIs, Databases, etc.

In web development, we have a layer where we define objects called Controllers, where we receive requests from a Front End, process that request and return a result, and we create those controllers with microframrworks like Express in Node.js, or Sinatra/Padrino in Ruby, or even with huge frameworks like Ruby on Rails, Django, etc.

Well, those controllers are just the gateway to our application business logic. That is the delivery mechanism.

Image got from the next article http://www.codingthearchitecture.com/2011/11/06/the_delivery_mechanism_is_an_annoying_detail.html

At Wizeline, we developed a chatbots platform to enable software engineers to build chatbots for our clients. At the end, some of the functionalities the clients wanted were:

Pull information from an external service and map it into carousels or other chatbot components, for example, fetching a list of restaurants from a service like Yelp, and map it into small cards with buttons to get to know the restaurants. Gather information from a user and take actions based on that, for example, create a meeting in your calendar based on the provided date and meeting length.

At the end, the core functionality of the chatbots was not at the chatbots listening mechanism layer, it was deeper into a business logic layer. Actually, the chatbot itself is just like a normal API, where we put some information and some operations are performed.

In an API, we would do a GET request, asking for some restaurants that serve Mexican food.

In the diagram, we see that there’s the Restaurants Controller (Delivery Mechanism), listening a requests for Mexican Food, and there’s a line separating that layer from the application logic of fetching information from an external service, and then building restaurant objects, which the Controller will interpret and return a result to our client.

Using a chatbot to get a list of restaurants should be something similar, by just changing the delivery mechanism layer:

In this diagram, we can see that the business logic layer where the mechanisms to fetch restaurants remain the same, so we can reuse those components to succeed the use case.

This is just an example where the chatbots can function as a delivery mechanism for systems, there can be examples where there are full conversations without any interaction with external systems and the user is just guided by the conversation logic defined to the chatbot.

Going a little deeper in the topic, I put a Bot Engine box in the diagram where all the conversation flow and the context are defined and prepared to know what to respond to a user message. So, the chatbot listener would act as a delivery mechanism for the Bot Engine, meaning that we could use another mechanism to interact with the bot engine, like a console application, RPC, sockets, etc.

I hope you have enjoyed this article and I’m more than happy to receive comments and solve any doubts :)