HOW TO DO IT: [Part 6 of 6]
For applications and services you need to do enough coding to understand your solution. This needs to be constrained to the minimum needed to prove the solution and high risk elements of your design.
For applications it’s all about state management. State management is all about UX. It’s influenced by where the user wants to go, and where they’ve been.
For services it’s all about processes and tasks. Service calls are business transactions.
In “The Method” the special sauce is volatility based decomposition. Services group methods by areas of volatility. For the application it’s the same with some nuance.
Volatility in your services will likely align with the axis of volatility: Across different customer types or across time for the same customer.
Volatility in your application includes these axis and adds the volatility of state management.
This application axis of volatility comes from design volatility and UX volatility. When designing services we ask what is likely to change. In an application what’s likely to change is state and state management (sometimes called the UX). This includes the UI. In other words, the design.
We’re not trying to limit or change design. UI/UX designers need to be free to create a quality experience for the user. What we need to do is minimize the impact of the various UI/UX designs on application state management. We want to group the core internal functions of the application by reas of volatility. These areas of volatility are likely to align with application states and state transitions.
The core functions of the application should reveal themselves in the UX diagram. The functions that support the UX workflow should be robust enough to handle the UI driving it.
This series attempts to describe the missing link between services and the application. The method prescribes that we group services by areas of volatility. We group application functions to protect against volatilites in the UI/UX. One way to do this is to encapsulate these volatilities behind a state machine.
One of the advantages using a state machine to encapsulate against volatility is you can use TLA+. TLA+ is a language for specifying state machines. Once you have your model specified in TLA+ you can use the model verifier to validate it.
Whether you create a formal specification or not, I suspect you’ll discover what I did. Understanding your state management needs allows you to understand how to encapsulate application level volatility. This encapsulation makes bugs more visible.
To sum up, the volatilities in your application are likely to be in the UI/UX workflow. Identify the application workflow early in the process. Using the application workflow you can encapsulate against likely changes. Perhaps by using a state machine.
I hope you found this discussion useful.
