Occasionally connected CQRS systems - Client and Server Commands - Task based screens

Question

Premise:

It is recommended that in CQRS+DDD+ES style applications use task based screens, these screens guide the user and capture intent.

These task screens can also be referred to as Inductive User Interface. Some examples of UI design guidelines that can help you create mondern, user-friendly apps:

Microsoft Inductive User Interface Guidelines and,

Index of UX guidelines

The way I understand it, the tasks, generally speaking, should line up with Commands or Functions waiting on the Server.

For example, if the User makes a change to the Customer's [first name], generally speaking this should be an isolated task where a pop-up window or the like provides a mechanism for this event, and this event only.

Questions:

Part-1:

In the situation where the User is not just making a change to a Customer's [first name], but actually creating a new Customer. Surely the User will not go from [first name] => to [last name] => to [address] => to [email], etc. -- in a wizard like style, where each wizard screen maps to a Command.

a) How are the screens laid out when it's just not practical to isolate a single task? For example when creating a new Customer or Inventory Item.

b) What does the code and/or logic flow related to the Commands look like on the Client and Server in this situation, keeping in mind the obvious pull to stay consistent with the "normal" task based flow of the rest of the system? After all, these all just translate to Activities or Events in the Event Source.

Part-2:

What if the User is not just making a change to a Customer's [first name], but their [last name], [address], and [phone number] -- all the while they User is off-line.

I think ultimately, the User should still be able to do real work on multiple tasks in different areas of the application, while off-line, and perform robust conflict resolution when coming back online.

a) What is the code and/or logic flow and/or artifacts related to the Commands on the Client side while the User is off-line while handling these events locally (IndexDb, queues, etc.)? and

b) What does the connection look like and how does it act when off-line (retries)?

c) What is the code and/or logic flow and/or artifacts related to the Commands on the Client and Server side, when the User comes back on-line?

d) What does the connection look like and how does it act when coming back on-line (reestablish of connection, if it is determined that the Client side ViewModel is stale, WebSockets, etc.)?

Reference diagram:

Answer 1

The way I understand it, the tasks, generally speaking, should line up with Commands or Functions waiting on the Server.

Or sometimes events, but the basic idea is right.

Surely the User will not go from [first name] => to [last name] => to [address] => to [email], etc. -- in a wizard like style, where each wizard screen maps to a Command.

No, we usually want a coarser grain than that. Some tasks do only require a single property, but several properties is a common case.

How are the screens laid out when it's just not practical to isolate a single task?

By grouping together cohesive units; consider the Amazon order workflow -- there are actually several different sets of data collected (the order itself, the selection of payment, specifying new methods of payment, specifying the delivery address, specifying the shipping priority....).

all the while they User is off-line.

See CQRS, not just for server systems; but in broad strokes - treat the data collected from the user as events (FormSubmitted) rather than commands. The offline device is the authority for tracking what the user did while off line; but the unavailable server is still the authority for the consequences of those events. So the server is responsible for the merge when the client reconnects.

The precise details might vary from one domain to another -- for instance, in a warehousing system, where the offline device has been collecting information about inventory, you might handle the inconsistencies that the server observes during the merge by raising exception reports (the device registered this package leaving the warehouse, but we have no record of it entering the warehouse).