Домен

В разработке слово чаще всего встречается в выражении «доменная модель» и в подходе Domain-Driven Design — предметно-ориентированном проектировании, которое Эрик Эванс описал в одноимённой книге 2003 года. Идея в том, что сложность программы определяется не технологиями, а бизнесом, который она обслуживает. Поэтому код строят вокруг понятий предметной области — «заказ», «отгрузка», «возврат», — а не вокруг таблиц и контроллеров.

Когда речь об адресе сайта, точнее говорить о доменном имени: регистрация, DNS и зоны — отдельная тема. Здесь — о домене как предметной области.

Ключевые понятия подхода

• Единый язык. Разработчики и заказчик называют вещи одинаково, и эти же слова становятся именами классов и методов. Если менеджер говорит «бронь», в коде не должно быть Reservation в одном месте и Hold в другом.
• Ограниченный контекст. Одно слово в разных частях бизнеса значит разное. Товар для склада — это габариты и остатки, для каталога — описание и фото, для бухгалтерии — номенклатурная позиция. Вместо одного гигантского класса делают несколько моделей, каждую в своих границах.
• Доменная логика — правила бизнеса: когда заказ можно отменить, как считается скидка. Её отделяют от инфраструктуры — базы данных, фреймворка, HTTP.

Пример: правило внутри доменной модели

final class Order
{
    public function cancel(): void
    {
        if ($this->status === OrderStatus::Shipped) {
            throw new DomainException('Отгруженный заказ нельзя отменить');
        }
        $this->status = OrderStatus::Cancelled;
    }
}

Правило «отгруженный заказ не отменяется» живёт в самом заказе, а не размазано по обработчикам форм, API и админке. Где бы ни вызвали отмену, проверка сработает одинаково. DomainException — стандартный класс исключения PHP, OrderStatus — перечисление статусов.

Когда подход нужен, а когда нет

Полноценный DDD окупается в системах со сложными правилами: CRM, учёт, логистика, B2B-порталы. Для сайта-визитки или блога такая архитектура избыточна — хватит возможностей CMS. Но привычка начинать проект с разговора о предметной области и единых терминах полезна всегда: она снижает число недопониманий между заказчиком и разработчиком. А границы контекстов подсказывают, как делить систему на микросервисы, если до этого дойдёт.