Question

My application has many modules and the original business flow looks like this:

A -> B -> C -> D

As the application grows, alternative flows are added to satisfy customers’ need:

A -> B -> C -> D

A -> B -> C’ -> D (C now can perform optional operations)

A -> D

A -> D’ (D now can perform C’s optional operations)

The numbers of unit test cases and QC’s manual tests rocket.

Current I have 2 solutions:

1. Silently create B, C from A before giving it to D, then I can guarantee the number of inputs to D
2. Skip B, C, adjust the input of D to a mediate type and write Adapter to convert the A -> mediate type

The chosen solution must meet below objectives:

• Flexible business (for customer)
• High processing performance
• Maintenance (source code)

I have no idea which one I should use or there is any better solution.

Answer 1

First, I am not entirely sure I understand your problem, so let me state my assumptions and then provide my answer. Adapt as necessary.

Assumptions:

• Your business process models sets of operations. Example: A could be a checkout step, and C and C’ be two different but similar payment steps.
• Each of the process steps operate on separate parts of a common data set. Example: B calculates totals and discounts (operate on cart contents), and C and C’ take the totals and initiate some sort of payment.
• You want to keep as much as possible of your existing implementation intact.

If this is the case, I would ensure that I had a proper understanding of my data model, and which parts each of the steps would operate on, and then build a state machine around this.

Benefits:

• Each of your process steps can be modelled using one or more states. You ensure that transitions are based on the data model. You could have a decision state that based on the user’s decision of paying using Paypal or redeeming a voucher transitions you to the appropriate state to handle this.
• States can be tested individually. Unit tests will be easy to write, and you can build harnesses for customer-facing functionality for manual testing (such as integration testing with a payment provider).
• State machines usually have a low footprint. They are normally event-driven, and thus keep the thread-count down in your application. If states only contain logic and only operate on data objects, you can even reuse state instances across different concurrent processes. This depends on your state machine framework.

Things to keep in mind:

• Be explicit in your states, and have many small states perform small dedicated operations. If a decision to go with card payment or vouchers arises, model this in a pseudo state.
• Avoid God objects (i.e. objects that contain know everything). If states start operating on large parts of the domain model, consider improving either the model or the state machine
• Make sure to make everything event-driven and asynchronous. Synchronous state machines won’t scale. If you are calling services that are not asynchronous, build a wrapper for it.

I have successfully employed this way of modelling a business flow in a previous project. It was a flow where end users could purchase objects. We needed to handle lots of alternative flows, such as switching between different ways of payment, retries when backend systems were unavailable and so on.

We rolled our own state machine framework for this to suit our needs. You should probably look at what is available for your platform.