Парадокс изучения DDD: там, где он действительно полезен, цена ошибки слишком высока для экспериментов, а там, где его можно спокойно применять ради практики, это чаще всего overengineering.
На простом проекте многих проблем, которые решает DDD, просто нет. Если внедрять его ради практики, проект станет сложнее, разработка займёт больше времени и будет стоить дороже. А отвечать на вопрос, зачем всё это было нужно, придётся тебе.
На сложном проекте всё наоборот. Есть сложная бизнес-логика, несколько команд, систему нужно декомпозировать и проводить границы между её частями. Здесь DDD уже действительно помогает. Но и ошибки стоят намного дороже, а опыта, чтобы их не совершать, как раз может не хватать.
DDD легко начать воспринимать как набор паттернов и пытаться применять их везде, где получается. В итоге можно самому построить слишком сложную архитектуру, а потом решить, что проблема в DDD.
Кроме того, реальные проекты не бывают пуристичными. Есть существующие базы данных, инфраструктура, интеграции и legacy. Всё это приходится учитывать, поэтому применять DDD строго по книжным примерам получается далеко не всегда.
На мой взгляд, важнее придерживаться принципов, которые лежат в основе DDD: понимать, какие проблемы он помогает решать, сохранять границы и общий язык с бизнесом, отражать домен в модели и коде, не тащить технические детали туда, где можно говорить на языке предметной области.
Конкретные техники при этом использовать выборочно, когда они действительно нужны.
