From Business Data To Business Processes (Part 3)
Users + Data + Transactions = Business Processes
In Part 1 I wrote that business data is graph-like. In Part 2 I wrote about transactions as a perferable mechanism to execute change in our graph. The last part connects both the graph and transactions to implement business processes and UIs on top.
GraphQL can be used as a business process engine, if all process-relevant data is stored inside our business data. And we should store all process-relevant data in our business data, else we need to pick up a phone and call somebody who has this information inside their brain.
On the technical-side GraphQL provides mechanisms to query and change data [1]. GraphQL uses the name mutation to change data. I think its a very bad name. But now it to late to change it…
GraphQL abstracts away the complex business data and provides domain-oriented names. I think thats why GraphQL is loved by frontend developers. They do not have to deal with most of the underlying business data complexity and get the data in a highly accessable way. GraphQL is not perfect, as it suffers from type explosion and context-dependend grammar.
I prefer Pathom [2, 3] over GraphQL. Pathom solves most of GraphQL nasty problems. Listen to the following talk:
At this point we use pathom to query the business data and change it. The last element we need are users and the roles they play inside the business processes on our system. Here comes dativity into play [4].
Dativity is a data-oriented business process engine. It uses a couple of clever tricks. First it models the state of a business processes implicitly via values of attributes. A dativity business process progresses by changing the values of its underlying attributes. No names needed to model the process state explicitly - like BPMN does. Remember there are only a few good names.
Second depending on values Dativity provides a list of available dativity actions (transactions). Its kind of auto-complete for business processes. This helps users to answer what can I do next - massive usability improvement.
Third it couples the available transactions to user roles. Thus dativity provides a basic authorization for actions. Its not a perfect for all situation. The kicker is the dativity library is super small.
Conclusion
GraphQL and pathom allows us to represent and change business data in an abstract way. This abstract data access in conjunction with dativity’s ability to provide user-roles for business processes, role-based actions and auto-completion allows to implement business processes in a flexible and minimal way. Next up will be user interfaces.
[1] GraphQL: https://graphql.org/learn/queries/
[2] Pathom: https://github.com/wilkerlucio/pathom
[3] Pathom-viz try it out, its very nice: https://github.com/wilkerlucio/pathom-viz
[4] Dativity: https://github.com/agentbellnorm/dativity