Сложно определить сложность сайта по ссылке, которую вы разместили.Я предполагаю, что вы сами управляете инвентарем и заказами вместо того, чтобы передавать эти задачи поставщику услуг.Я также предполагаю, что вы не можете остановить разработку функций во время процесса миграции.
Самое важное для любого устаревшего проекта миграции - это сначала установить Inversion of Control в устаревшем коде.Это даст возможность выделить отдельные проблемы, которые сейчас, вероятно, тесно связаны.Без IoC вам будет тяжело.Обратите внимание, что внедрение конструктора не является началом процесса переноса устаревшего приложения.Вместо этого вам придется использовать шаблон Service Locator и помнить о внедрении конструктора или свойства в будущем.
Как только у вас будет контейнер IoC, вы можете начать искать швы для разрыва сервисов.Вы, вероятно, найдете код, который естественным образом поддается внутренним службам, поэтому рефакторинг их должен разрешать локатор служб.Системный регистратор - хорошее место для начала.
Цель первых нескольких месяцев - перейти на сервис-ориентированную архитектуру, где большая часть бизнес-логики содержится либо в сущностях домена, либо в службах.Не думайте о том, чтобы получить идеальную архитектуру с самого начала - это невозможно.Процесс миграции включает в себя переход от вонючей архитектуры к архитектурам с постепенно меньшим количеством запахов, а не от монолитного напрямую к модульному.Просто извлеките бизнес-логику из пользовательского интерфейса и контроллеров, и позже вы сможете настроить параметры для уровня домена или уровня приложения.
Обратите внимание, что здесь также большое внимание уделяется репозиториям.При переходе на службы вы также должны перенести весь доступ к БД, чтобы использовать шаблон репозитория.Это откроет дверь для реального модульного тестирования.
Когда вы перенесете код для использования служб, репозиториев и IoC, вы начнете видеть швы, где вы можете разбить некоторые функции на API.Создайте первый API только с одной небольшой функцией и реорганизуйте свой монолит, чтобы использовать его.Сделайте его небольшим, потому что это потребует большого количества изменений инфраструктуры и процессов, и вы хотите сделать как можно меньше одновременных изменений.Как только вы выделите этот первый API, продолжайте переносить все больше и больше функций в этот API.
Кстати, самое время перейти к архитектуре CQRS и стратегии DDD.Этот первый API должен быть полностью ограниченным контекстом и реализован с использованием CQRS.
Удачи!
Кстати, я написал книгу именно об этом.Он ориентирован на .NET, но этот процесс подходит для любого языка.Ищите «Брэдли Ирби» на Amazon.