Designing an application typically involves focussing on the application requirements from various angles and thus arriving at different design objects and functions and the triggers when these functions are executed. Once done, these are translated into a coherent “functional design” which then gets translated into a “technical design”.
A functional design stays at the level of business objects, business functions and transactions. For eg., in a warehouse management system, “When a user scans the barcode on a truck, the receiving process is invoked”. The trigger here is the “scan of barcode”, the business function is “receiving process”. What is a “receiving process” is also detailed in a functional design. A technical design goes deeper and translates each of these business objects and functions into classes, methods and data store and such. This is then converted into code. For eg., in the above “Truck/Trailer” class is present, which has a method called “barcodeScanned”, this then calls the receiving process functions.
Typically, a technical design has design of data that has to be stored, APIs that are exposed, functional logic that is invoked during an API call or on regular basis and UI/UX that determines how a user interacts with the application.
This introduces a number of touch points that need to transfer knowledge accurately for the final product to resemble the requirements. The person translating the requirements to functional design needs to have understood the problem, the person translating the functional design to technical design needs to understand the problem and the person coding the technical design needs to understand the problem. It should also be noted that this information flows from a person with the highest understanding of the problem to a person with the least understanding of the problem and hence details tend to get lost in this chain.
A better approach will be where functional design is directly translated to code and can be deployed. This allows the person with the best knowledge of both the system and the requirements to also be the person who produces code and hence the integrity of the requirement is maintained. A state machine based platform allows us to do just this, with the least amount of code generated, it allows the code to be as close as possible to the functional design of the system.
In a state machine based system, a typical application design can be broken down into the following steps:
- Identify the business objects and their attributes.
- These are the objects that are stored and can be retrieved back
- Various business functions of the application acts on one or more of these business objects.
- Read More …
- Identify the various states for each of these business objects
- These states can be strung together to form a long running business transaction.
- Business functions can act only on business objects in certain given states
- Read More …
- Identify the users of your system and business events that trigger various business functions
- These business event occur for a specific business object in a given state
- These events can modify the current and other business objects
- These business events become API that you want to expose and triggers a business function
- Read More …
- Identify the business logic that needs to run for each of these business events.
- Business logic is split into multiple standard logic strung together to form a single sequence.
- Read More …
- Segregate the business functions that needs to complete immediately from those that can be run offline
- These can then be split into two logic one triggered directly by the business event and one triggered on an internal message.
- Design the UI/UX and the page flows between the different pages.
- Identify the business events that will be triggered from the various UI/UX pages.
The above should typically get the design going for simple applications. Complex applications need more steps to split logic to manageable pieces and involves the below steps:
- Identify the modules that you want to split the applications into
Define which data belongs to which module - Decide on the logic to be executed for each API and the data that needs to be acted upon.
- Create the split as multiple modules which interact with each other instead of just one module.
Published on Java Code Geeks with permission by Raji Sankar, partner at our JCG program. See the original article here: How to design using state machines? Opinions expressed by Java Code Geeks contributors are their own. |
