Когда DDD вам НЕ нужен (и когда нужен)

DDD - это не про структуру папок. Это про борьбу со сложностью.

Самая большая ловушка: прочитав Эванса или Вернона, начать пихать DDD в простой CRUD. Если ваше приложение просто перекладывает JSON из запроса в базу, DDD сделает разработку в 3 раза дороже и медленнее.

🚦 Когда DDD избыточен:

💜Админки, простые CMS.
💜Микросервисы-прокси.
💜Прототипы (MVP), которые нужно выкинуть через месяц.

🔥 Когда DDD необходим:

💜Сложный бизнес-процесс: (например, расчет налога с учетом льгот, региона и фазы луны).
💜Долгоживущий проект: (вы будете поддерживать это 3+ года).
💜Важность языка: Когда менеджер говорит «списать бонус», а в коде это $user->points -= 10. Это рассинхрон, который приведет к багам. В DDD это будет $user->debitBonuses(10).

Главный принцип:
DDD применяется не ко всему проекту целиком, а к Core Domain (Ядру). Вспомогательные модули (отправка почты, логи) могут и должны оставаться простыми.

Вывод: Не стройте "Звезду Смерти" для доставки пиццы. Сложность архитектуры должна соответствовать сложности бизнеса.

Ставь ❤️, если видел "Hello World" на DDD с 15 интерфейсами.

#ddd #architecture #php #strategy

📲 Мы в MAX

👉 @php_lib

Анемичная модель vs Богатая модель

Ваши сущности, это просто "мешки для данных"?

Типичная ошибка (Anemic Domain Model):
У вас есть Entity Order, в которой только геттеры и сеттеры. А вся логика лежит в гигантском OrderService на 2000 строк.

❌ Как это выглядит (Анемия):

// Service
$order->setStatus('paid');
$order->setUpdatedAt(new DateTime());
// А вдруг забыли отправить ивент?
// А можно ли менять статус на 'paid', если сумма 0? 
// Сервис должен всё помнить.
$repo->save($order);

✅ Как должно быть (Rich Model):
Переносим бизнес-логику внутрь сущности. Принцип "Tell, Don't Ask" (Говори, а не спрашивай).

class Order 
{
    // Свойства приватны! Извне их менять нельзя.
    private string $status;
    private array $items = [];

    public function pay(Payment $payment): void 
    {
        if ($this->status === 'paid') {
             throw new DomainException("Order already paid");
        }
        
        if ($payment->amount < $this->getTotal()) {
             throw new DomainException("Not enough money");
        }

        $this->status = 'paid';
        $this->recordEvent(new OrderPaid($this->id));
    }
}

// Service становится тонким и скучным (и это хорошо!):
$order->pay($payment);
$repo->save($order);

Суть: Сущность сама следит за своими инвариантами (правилами). Вы физически не можете перевести её в некорректное состояние. Сервисы просто дирижируют процессом, но не знают деталей бизнес-правил.

Где сейчас живет ваша логика? В сервисах или в моделях?

#ddd #architecture #oop #refactoring

📲 Мы в MAX

👉 @php_lib