Temporal Workflow as domain object (DDD), and manage domain object state

Community Support
,
1

Hi,

I’m developing a Warehouse Management System (WMS) that handles the storage and retrieval of parcels at specific locations (bins) within a warehouse facility. The WMS requires high traceability and will likely be event-sourced. Some of the events that may need to be handled include ParcelsReceived, ParcelStored, and ParcelDispatched. All of these events are part of well-defined workflows that warehouse operators complete daily. For example, an operator might unload parcels and store them in pre-defined zones.

Context:

The WMS should track who did what (Task Management).

A warehouse task is a long-running workflow and may require compensation actions (e.g., handling receiving damaged goods).

Workflows highly depend on Service Level Agreements (SLAs), such as storing cold or fragile goods in pre-defined areas or zones.

The nature of this application is inherently asynchronous (e.g., multiple operators unloading one truck, multiple operators picking one order). Therefore, Temporal is a great fit as a platform for managing these complex workflows.

The WMS should keep track of where parcels are stored (location), which bins are available, and maintain a history of all parcel movements inside the warehouse facility. Thus, event sourcing is likely needed.

The warehouse tasks (Receive, Dispatch, etc.) are Temporal Workflows.

The course “Interacting with Workflows with Python”

module “Finding Workflows with Search Attributes” suggests:

Storing state in a local variable and exposing it with a Query.

Storing and retrieving state in an external datastore via Activities.

Questions:

Do I need duplicate task state (workflow local variable, datastore)?

How long does Temporal keep the workflow state stored in its database?

If using an external event-sourced datastore, do you recommend the workflow saves its state via an activity?

2

There is no need to duplicate information stored in workflow variables in a separate database. The main reasons to use an external DB are:

  1. Indexing and aggregation. Suppose you need to search for specific information and aggregate it across multiple workflows in some application-specific way.
  2. Historical records. A completed workflow is deleted after the retention period. So if you need to keep the data for a long time, you can push it to a DB at the end of the workflow.
  3. Sometimes, multiple clients need high-frequency polls for a specific workflow state. Queries are not optimal if the rate of such requests is pretty high. In this case, polling an external DB/Redis might be a reasonable optimization.
1 Like