Z>Сложность в правилах конвертации. Они достаточно сложные и неочевидные.
Z>Где же их еще реализовавыть как не в Бизнес-слое (domain-model)?

Опять же, допустим.
Я просто пытаюсь донести, что DDD — это не только про код, это прежде всего про shared mental model системы, выраженную в коде.
И есть у меня ощущение, что если спросить вашего доменного эксперта о правилах конвертации из старой БД в новую, то он сильно удивится.
Потому что в его картине мира есть Организации, Договора, Контрагенты. А вот БД там скорей всего нет.
Как нет и процесса конвертации из одной БД в другую.
Т.е. конвертация — это такая чисто техническая деталь, с доменом вообще никак не связанная.

Опять же, допустим, что я ошибаюсь.
И в картине мира доменного эксперта присутствуют и Договор Старого Формата, и Договор Нового Формата.
И он выдал вам вполне конкретные правила конвертации.

Тогда в терминах DDD у нас есть сущности ДоговорСтарогоФормата и ДоговорНовогоФормата и есть процесс конвертации.
А такой процесс обычно моделируется доменным сервисом, e.g.

// Это лежит в сборке Domain.dll
class ContractConvertor {
  public Contract Convert(OldContract contract) { 
    // Тут создание нового контракта
    // Применение бизнес-правил конвертации
  }
}

А где-то уровнем выше есть application service, который этим доменным сервисом оперирует:

// Это лежит в сборке Application.dll, которая рефренсит Domain.dll и, e.g. Infrastructure.Storage.Contracts - для интерфейсов репозиториев
class ConvertionService {
  private IContractRepo _contracts;
  private IOldContractRepo _oldContracts;
  private ContractConvertor _convertor;

  public Contract ConvertContract(int oldContractId) {
    var oldContract = _oldContracts.LoadById(oldContractId);
    var contract = _convertor.Convert(oldContract);
    _convertor.Save(newDocument);
    return contract;
  }
}

Z>Сложность в правилах конвертации. Они достаточно сложные и неочевидные.
Z>Где же их еще реализовавыть как не в Бизнес-слое (domain-model)?

Опять же, допустим.
Я просто пытаюсь донести, что DDD — это не только про код, это прежде всего про shared mental model системы, выраженную в коде.
И есть у меня ощущение, что если спросить вашего доменного эксперта о правилах конвертации из старой БД в новую, то он сильно удивится.
Потому что в его картине мира есть Организации, Договора, Контрагенты. А вот БД там скорей всего нет.
Как нет и процесса конвертации из одной БД в другую.
Т.е. конвертация — это такая чисто техническая деталь, с доменом вообще никак не связанная.

Опять же, допустим, что я ошибаюсь.
И в картине мира доменного эксперта присутствуют и Договор Старого Формата, и Договор Нового Формата.
И он выдал вам вполне конкретные правила конвертации.

Тогда в терминах DDD у нас есть сущности ДоговорСтарогоФормата и ДоговорНовогоФормата и есть процесс конвертации.
А такой процесс обычно моделируется доменным сервисом, e.g.

// Это лежит в сборке Domain.dll
class ContractConvertor {
  public Contract Convert(OldContract contract) { 
    // Тут создание нового контракта
    // Применение бизнес-правил конвертации
  }
}

А где-то уровнем выше есть application service, который этим доменным сервисом оперирует:

// Это лежит в сборке Application.dll, которая рефренсит Domain.dll и, e.g. Infrastructure.Storage.Contracts - для интерфейсов репозиториев
class ConvertionService {
  private IContractRepo _contracts;
  private IOldContractRepo _oldContracts;
  private ContractConvertor _convertor;

  public Contract ConvertContract(int oldContractId) {
    var oldContract = _oldContracts.LoadById(oldContractId);
    var newContract = _convertor.Convert(oldContract);
    _convertor.Save(newContract);
    return newContract;
  }
}