Когда 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

Value Objects (Объекты-значения) - самый быстрый выигрыш

Хватит страдать от «Primitive Obsession»!

В большинстве легаси-проектов я вижу такое:
function register(string $email, string $phone, float $amount)

Что тут не так?

1. string $email - это просто набор байт. Там может быть "asdf", и PHP это проглотит.
2. Валидация размазана по контроллерам и сервисам.
3. Логика (например, форматирование телефона) дублируется.

✅ Внедряем Value Object:

readonly class Email 
{
    public string $value;

    public function __construct(string $value) 
    {
        if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException("Invalid email format");
        }
        $this->value = strtolower($value); // Нормализация
    }
    
    public function getDomain(): string 
    {
        return explode('@', $this->value)[1];
    }
}

// Теперь сигнатура метода говорит правду:
function register(Email $email, Phone $phone, Money $amount) { ... }

В чем профит:

💜Гарантия: Если у тебя в руках объект Email, он 100% валиден. Не надо проверять это снова.
💜Инкапсуляция: Логика живет внутри класса, а не в Helper::formatPhone().
💜Immutability: Value Object нельзя изменить, можно только создать новый. Это спасает от сайд-эффектов.

Совет: Начните внедрение DDD именно с Value Objects (Деньги, Координаты, Email, SKU). Это дешево и сразу чистит код.

Напишите в комментах, для чего вы уже используете VO? 👇

#ddd #valueobjects #refactoring #php82

📲 Мы в 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

Совет по Laravel 💡: Метод «diffInDaysFiltered»

Вам когда-нибудь требовалось подсчитать количество дней между двумя датами при фильтрации по условию? Поскольку Laravel использует Carbon под капотом, вы можете использовать «diffInDaysFiltered», чтобы сделать именно это 🚀.

#laravel

📲 Мы в MAX

👉 @php_lib

Совет по Laravel 💡

Легко обновляйте столбцы JSON с помощью синтаксиса стрелок Laravel! Используйте -> для указания конкретных ключей в ваших JSON-данных. Работает с MariaDB 10.3+, MySQL 5.7+ и PostgreSQL 9.5+.

📲 Мы в MAX

👉 @php_lib

Админ vs студент: разбор тестового задания — сервис консультаций на Laravel за неделю

Эта статья — подробный разбор тестового задания на позицию PHP-разработчика, которое мне пришлось выполнить в краткие сроки из-за приближающей сессии. Я расскажу, с какими трудностями столкнулся, будучи студентом и новичком в веб-разработке, как построил архитектуру проекта «Школьные консультации» и что из этого вышло. Если вам интересен взгляд «с первоначального этапа» на классическую задачу или вы хотите узнать, чем всё кончилось, или у вас был похожий опыт (о котором вы хотели рассказать), то добро пожаловать.

https://habr.com/ru/companies/ruvds/articles/983692/

📲 Мы в MAX

👉 @php_lib