Просто писать как пишется.

Примените архитектурные границы. Реализуйте сначала всю бизнес логику. Интерфейсы, как dependency injection оставьте для последующего принятия решений о деталях вводы/вывода, развертывания, хранения. Чем дольше вы будете откладывать решение о выборе окончательного варианта технологии тем лучше, пока реализуете бизнес логику, поймете после 100500 итерации требований, кастдева гениальных идей из маркетинга и т.д и т.п. где что и как хранить, как оповещать, стоит ли использовать фреймворки или нативные технологии. Вам нужно только определиться с ресурсами и начальным объемом пользователей. Также необходимо спроектировать приложение так, чтобы оно легко разбиралось на микросервисы и обратно в монолит. На начальном этапе вы не знаете как пойдет на практике развитие вашего продукта и какой объем будет. Зависимость от других систем следует также сделать минимальной или свести к нулю.

Ну вы же изучали SOLID, всякие паттерны проектирования. Используйте эти знания на практике, заодно прокачаете навыки

Без методологии процессов и архитектуры потом будет очень грустно. 😕 можно описать все процессы, но на чём будут существовать эти процессы? Где будут жить данные, как будут взаимодействовать различные системы между собой? Что в составе автоматизации? Управление запасами, складская логистика? управленка как-то должна собираться в ERP в итоге. А если там ещё нужно Cad/cam/cae, то тут и pdm нужно подвязать. Может я сгущаю краски, но правда интересно, как без архитектора?

Примерно никак, это как дом без фундамента.

Много рисков… нет концепции, общего технического решения и т.д.