Какие подходы для работы со сложными формами работают?

public class MainViewModel 
{
    public Field1 Field1{get;set;}
    public Field2 Field2{get;set;}
    public ViewModel1 ViewModel1{get;set;}  
    public ViewModel2 ViewModel2{get;set;}  
    public ViewModel3 ViewModel3{get;set;}  
}

public class ViewModel1
{
    public Field3 Field3{get;set;}
    public ViewModel1(MainViewModel main)
    {       
    }
}
public class ViewModel2
{
    public Field4 Field4{get;set;}
    public ViewModel2(MainViewModel main)
    {
    }
}
public class ViewModel3
{
    public Field5 Field5{get;set;}
    public ViewModel3(MainViewModel main)
    {
    }
}

public class ViewModel1
{
    public Field3 Field3
    {
        get => _field3 
        set 
        {
            var oldValue = _field3; 
            if (SetProperty(ref _field3, value))
            LocalBus.Raise(new Field3Cahnged(oldValue, value))
        }   
    }
    public ViewModel1(MainViewModel main)
    {       
    }
}
public class ViewModel2
{
    public Field4 Field4{get;set;}
    public ViewModel2(MainViewModel main)
    {
        LocalBus.Subscribe<Field3Cahnged>(ev => {.. logic ..});
    }
}

Боюсь показаться банальным, но принципы SOLID пока еще никто не отменял:

1. Классы вью моделей не должны зависеть от других вью моделей напрямую, только от абстракций (интерфейсов). Уменьшение прямых зависимостей заметно облегчит юнит тестирование.
2. Ответственность вью модели - контролировать состояние вьюхи на основе модели и выступать между ними посредником. Не пытайтесь уместить всю бизнес логику во вью модель, этим должны заниматься сервисы.
3. Шина (медиатор) во многом является анти-паттерном, так как делает зависимости между компонентами неочевидными. Иногда это бывает полезно, но, скорее всего, не в вашем случае. Советую рассмотреть вариант коммуникации через модель/сервисы (когда вью модели подписываются на изменение состояния модели). Шине можно оставить нейтральные нотификации, от которых не зависит поведение конкретной вью модели (например "значения свойства изменилось", но при этом вью модели безразлично кто и как среагирует на эту нотификацию).
4. Избежать проблем с многопоточностью (в частости race condition) можно с помощью очереди background операций, с возможностью их отмены в любой момент (т.е. некое подобие Dispatcher-а).

Неоднократно приходится сталкиваться с подобными проблемами, поэтому выскажу свои мысли по этому вопросу:

Запутывание начинается с момента когда дочерняя VM начинает знать о родительской VM.

Бизнес-логика должна быть в модели. Если это правило не соблюдается, то она размазывается по вью-моделям, что приводит к двусторонней связи между дочерней и родительской VM.

public class MainViewModel 
{
    public Field1 Field1 { get; set;}        
    public ViewModel1 ViewModel1 { get; set;}
    ModelModel mainModel;
}
public class ViewModel1
{
    public Field3 Field3{get;set;}
    public ViewModel1(MainViewModel mainVM)
    { 
    }
}

в дочернюю VM необходимо передавать либо часть главной модели, либо всю модель сразу(как в вашем случае). Оттого и ViewModel и переводится как "представление модели" потому что она представляет модель, а не вью-модель не правда ли?)

public class ViewModel1
{
    public Field3 Field3{get;set;}
    public ViewModel1(MainModel model)
    { 
    }
}

"двустороннюю" связь можно реализовать через события модели. Главная/дочерняя вью-модель подписываются на нужные события модели и реагируют на изменения.

public class ViewModel1
{
    public Field3 Field3{get;set;}
    public ViewModel1(MainModel model)
    { 
        model.SomePropertyChanged += modelSomePropertyChanged; 
    }
    void modelSomePropertyChanged(object sender, EventArgs e)
    {
        //что-то делаем...
    }
}

Вероятно, логика модели должна быть отделена от логики вьюмоделей. При этом встаёт вопрос - а как будут общаться модели разных секций?

Разные секции получились в результате дробления главной модели и они должны быть между собой связаны? Вероятно лучше оставить одну большую модель, нежели раздробить ее на мелкие. Тот случай когда дробление больше усложняет чем упрощает.

Вариант 1. Бывает, что трудность реализации вызвана проблемой X/Y. Заказчик, имея проблему X, но не обладая техническими знаниями, предполагает, что эта проблема решается способом Y и просит сделать Y. Программист делает Y, но этот способ сложный, плохо ложится на парадигму реляционных данных, или объектов, или другую известную парадигму. Оказывается, что если попросить программиста решить задачу X, он предложит другое решение, гораздо более простое.

Типичный пример: медленные запросы к базе. Если спросить человека, который просит отчёт на 30 страниц, что он с ним будет делать, окажется, что он планирует просматривать его глазами в поисках каких-то важных данных. Но с этой работой гораздо лучше справляется компьютер, и для этого нужен другой запрос, гораздо более простой и производительный.

Поэтому первая рекомендация: ещё раз рассмотреть сценарии использования. Возможно, вместо одного сложного приложения лучше написать три простых для трёх разных ролей.

Вариант 2. Циклы в зависимостях возникают при попытке «формализовать неформализуемое». Предположим, есть поле A, от которого зависит поле B, а от того, в свою очередь — поле C. Построим направленный граф, и, если он ациклический, то формально мы можем построить модель и протестировать её. Но если вдруг поле A зависит от C, граф циклический, и у нас проблема. Уточню, что ациклический граф, это не всегда дерево, в нём ветки могут и сходиться, но они не образуют циклов.

Один из способов решения этой проблемы предложил Купер в своей книге «Психбольница в руках пациентов». Вы не пересчитываете C при изменении A, а проверяете попадание в диапазон. Если не попали, показываете это пользователю, но не запрещаете дальнейшее редактирование. Похожим образом действует проверка правописания: вы видите те слова, которые не известны программе, но сами решаете, ошибается программа, или нет. Если программа ошибается, вы просто игнорируете то, что подчёркнуто красной чертой. Но опечатку вы не пропустите.

Вариант 3. Подходящий инструмент. Бывает и так, что правила вполне можно формализовать, но сам язык не очень подходит для решения этой задачи. Часто нужно что-то вроде Пролога. Решением здесь являются кодогенерация и предметно-ориентированные языки (domain specific languages, DSL), которые можно использовать и в паре.

Например, вы можете описать бизнес-правила на языке собственной разработки, и при сборке проекта компилировать его в основной язык проекта. В современных ОО-языках наподобие C++, Java, C# хорошим решением является так называемая текучая нотация (fluent syntax), когда цепочка методов записывается через точку.

Скажем, в Entity Framework такой своеобразный DSL используется для описания отображений из БД в объекты:

public void Configure(EntityTypeBuilder<OperationData> builder)
{
    builder.HasOne(x => x.Order)
           .WithMany(x => x.Operations)
           .HasForeignKey(x => x.OrderId)
           .OnDelete(DeleteBehavior.Restrict);
}

Здесь с помощью цепочки методов строится модель, которая может быть даже формально проверена специально написанным методом.

Эта тема подробно освещена Фаулером сотоварищи в книге о предметно-ориентированных языках.