The "Big Save" Problem: Why Task-Based UI is Event Sourcing’s Best Friend

You've sold the team on Event Sourcing. You're excited about the audit trails, the time-travel debugging, and the rich history of your domain. You've modeled your aggregates and defined your events.

Then you look at the UI designs.

It's a giant "Edit Profile" screen. Fifty fields. Tabs for address, preferences, bio, and settings. And at the bottom, one solitary button: Save.

This is the "Big Save" problem, and it’s where many Event Sourcing implementations stumble. How do you translate a massive, generic state change into the specific, meaningful events your architecture craves?

The answer isn't in better backend diffing logic—it's in rethinking the User Interface itself. Enter Task-Based UI.

The Conflict: Context vs. CRUD

In a traditional CRUD (Create, Read, Update, Delete) application, the "Big Save" is fine. You map the form fields to a database row, overwrite the current values, and move on. The database knows what is true right now, but it has no idea how or why it got there.

Event Sourcing demands more. It thrives on Intent.

• Did the user change their last name because they fixed a typo? (NameCorrection)
• Did they change it because they got married? (NameChangedDueToMarriage)

To a "Big Save" screen, these look identical: LastName changed from "Smith" to "Jones."

If you send a generic UpdateUser command to your backend, you've already lost the game. Your event store becomes a graveyard of UserUpdated events, stripping away the rich business narrative you promised to deliver. You can't trigger a "Send Congratulatory Email" side effect effectively because you don't know if they got married or just couldn't spell "Smith."

Task-Based UI: Aligning Actions with Events

Task-Based UI (also known as Inductive UI) flips the script. Instead of presenting a screen that reflects the structure of your data (tables and columns), it presents an interface based on user goals and processes.

In a Task-Based UI, you don't just "Edit User." You choose specific actions:

• "Relocate User"
• "Correct Name Typo"
• "Change Subscription Level"

This simple shift aligns your UI 1:1 with your Domain Events.

1. Capturing the "Why" (Intent)

When a user clicks "Relocate User," the UI can present a focused wizard asking for the new address. When they submit, the intent is unambiguous.

CRUD Approach: User edits Address -> UpdateUser Command -> UserUpdated Event (Maybe check if address changed?)

Task-Based Approach: User clicks "Move" -> RelocateUser Command -> UserRelocated Event

Now, your downstream processors can react intelligently. The UserRelocated event might trigger a tax recalculation service or a shipping zone check. A separate CorrectAddressTypo task would trigger neither.

2. Intuitive User Experience (UX)

Engineers often fear that breaking a big form into smaller tasks will annoy users. "Won't more clicks make them mad?"

Actually, it often reduces cognitive load. This is the difference between handing someone a 50-page contract to edit versus asking them, "What would you like to change?"

• Guidance: You can guide the user through complex validations specific to that task. If they are downgrading a subscription, you can show a warning about losing access to features—something that's hard to cram into a generic "Edit Settings" tab.
• Discovery: Verbs are powerful. A button that says "Suspend Account" is easier to find and understand than a checkbox buried in a grid labelled IsActive = false.

3. Better Feedback Loops

"Record Saved."

We've all seen that message. It's technically true, but emotionally empty.

With Task-Based UI, the system can speak the user's language:

• "Success: User has been relocated to the NY office."
• "Error: Cannot downgrade subscription while an active billing cycle exists."

The feedback confirms the intent was understood and executed.

Examples in the Wild

You probably use Task-Based UIs every day without realizing it.

• Amazon: You don't "Edit Order." You "Track Package," "Return Item," or "Buy Again."
• Banking: You don't edit your balance in a grid. You "Transfer Funds" or "Deposit Check."
• HR Experience:
  • CRUD: Open employee grid, find "Salary" column, change 50,000 to 55,000, click Save.
  • Task-Based: Click "Give Raise." System asks for new amount and the reason (Merit, COLA, Promotion). System records the event SalaryIncreased with the reason attached.

Implementation: The CQRS Fit

Task-Based UI fits naturally with CQRS (Command Query Responsibility Segregation).

1. Read Side (The View): The user sees the current state (the Profile Page). This page helps them decide what to do.
2. The Trigger: The user selects a task (e.g., "Change Password").
3. The Modal/Wizard: A small, dedicated UI component appears. It captures only the data needed for that specific command.
4. Write Side (The Command): The UI sends a specific command ChangePassword { UserId, NewPassword }.
5. The Event: The domain model processes the command and emits PasswordChanged.

This decouples your UI validation logic. You no longer have one massive validation schema for the User object. You have small, simple validators for each command.

Conclusion

If you are struggling to make Event Sourcing work because your events feel generic and meaningless, look at your UI. The "Big Save" might be the villain.

By adopting a Task-Based UI, you:

1. Preserve Intent from the user's brain to the event store.
2. ** Simplify Validation** by isolating complex logic into specific workflows.
3. Enable Powerful Side Effects that react to specific business reasons, not just data changes.
4. Create a More Guidable UX that helps users complete their goals with confidence.

Don't let your UI flatten your domain. Let the user's intent drive the architecture.