So far, we have seen how a set of activities constitute a single transaction. The underlying intent of breaking down a transaction into granular level of activities is to promote the scope of reusability. By reusability, I mean to say the reusability of generic functions. More granularity will ensure more similarity towards a generic functions, thus more opportunity to use those.
Let's take the example of money transfer between account A and B as I mentioned before. If we go by the set of five activities, each one represents an opportunity to reuse a generic function. Let's consider the Activity #1: Check that account balance of A is greater than or equal to 500. This one can be implemented using a function similar to
bool HasSufficientBalance (string accountID, long balanceRequirement)
The parameters are accountID to make a query into the accounts database to get the balance, and the balanceRequirement is to measure whether the condition satisfies or not. If such a function does not exist the objective should be to develop such a function which can be used to implement the current requirement as well as can be used for future application development.
Having such functions developed and ready for reuse, we can easily reuse them by calling from a requirement specific program, organize and execute those in the required sequence, and get the desired output, or complete the specified transaction.
There comes the benefits of having functions for generalized activities, where each function can be idenfied with a generic intent to perform a single of task.
