Тут есть очень тонкий момент ... с одной стороны DDD как раз говорит о том, что нужно разделять модели по контекстам, с другой стороны - на ранних этапах это сильный оверинжиниринг.
Мне видится, что истина - где-то посередине. Т.е. не стоит стремится на старте сразу сделать "полную и правильную" карту контекстов, это все равно невозможно - придут новые вводные и карту придется перестраивать, и чем больше наработали по этой карте, тем больше придется переписывать.
С другой стороны, совсем без карты нельзя, поэтому в каждый момент времени должна быть актуальная гипотеза о будущей целевой карте контекстов (та, в которую мы верим и которую подкручиваем по мере появления новых вводных), и одновременно упрощенная карта текущего состояния, в которой может быть какие-то контексты объединены, какие-то отсутствуют, но у нас есть четкое понимание как, в какой ситуации и какие изменения модели будут предприняты, чтобы прийти к целевой карте.
Это означает, что мы, действительно, можем начать с простого монолита, например, с общей модели заказа, но эта модель развивается не стихийно, а мы как бы закладываем ростки будущего разделения в архитектуру, в принципы построения системы, и разваливаем контексты и модели на части, как только возникает такая необходимость.
с одной стороны, такой подход позволяет избежать лишних усложнений на старте, а с другой, его реализация требует еще более высокой квалификации, опыта и "насмотренности", чтобы контролировать архитектурные принципы еще до того, как они нашли фактическое воплощение в реальном выделении модулей, интерфейсов и сервисов.
Грубо говоря, писать простой код оказывается еще сложнее, чем писать сложный :)