В независимости от модели данных, используется только два чистых подхода:
1. сохранение состояние всей программы, при undo/redo восстановление состояния на каждом шаге
2. преобразование каждого действия в команду и антикоманду. А далльше при U/R последовательное исполнение либо команд, либо антикоманд.

1 подход в чистом виде редко применяется, обычно его оптимизируют — сохранение только измененных частей программы и т.д, как-то совмещают со вторым подходом и т.д.

у этих подходов разные плюсы и минусы:
первый подход: стабильнее, быстрее в разработке (надо один раз написать две функции save и load),
но более ресурсоемкий при исполнении
второй -  менее надежный (есть вероятность, что антикоманда не полностью соответствует команде), более трудоемкий (каждое действие надо превратить в пару: команда-антикоманда), зато очень выгодный при исполнении (нет лишних затрат, меняется только то, что должно менятся).

На практике, начинают U/R делать с двух сторон:
1. Реализуют первый подход, благо его писать быстро.
2. Далее реализуется второй подход: те действия, которые легко перевести в команды-антикоманды переводятся,
те действия, которые не получилось быстро перевести, оформляются в виде команды-антикоманды (каждая их которых восстанавливает все состояние).
3. Далее делается движение с двух сторон: все больше делается "честных" команд-антикоманд,
а при сохранение состояния пытаются сохранять только часть программы. Например, для команды "отсортировать массив" — можно сохранять только состояние самого массива.

Полностью сохранение состояния не убирают, а используют для сохранения контрольных точек (например, каждые 10-50 действий пользователя) для того, чтобы уменьшить проблему "антикоманда не полностью соответствует команде"