Предметно-ориентированный Laravel

Во — первых, я не придумал термин “домен” – я получил его из популярной парадигмы программирования DDD, или “доменного дизайна”. Согласно Оксфордскому словарю, “домен” может быть описан как “определенная сфера деятельности или знания”.

Хотя мое использование слова “домен” не будет точно означать то же самое, что и при использовании в DDD, но есть несколько сходств. Если вы знакомы с DDD, вы обнаружите эти сходства на протяжении всей этой книги. Я старался изо всех сил упоминать о любых совпадениях и различиях, когда это было уместно.

Итак, Домены. Вы также можете назвать их “группами”, “модулями”; некоторые люди называют их “услугами” или “сервисами”. Какое бы название вы ни выбрали, Домены описывают набор бизнес-задач, которые вы пытаетесь решить.

Давайте приведем пример: приложение для управления бронированием отелей. Он должен управлять клиентами, бронированиями, счетами-фактурами, инвентаризацией отелей и т. д.

Современные веб-фреймворки учат вас брать одну группу связанных понятий и разбивать ее на несколько частей по всей вашей кодовой базе: контроллер с контроллерами, модели с моделями.

Клиент когда-нибудь говорил вам “поработай с массивами на всех контроллерах” или “проведи некоторое время в каталоге моделей”? Нет — они просят вас работать над выставлением счетов, управлением клиентами или функциями бронирования.

Эти группы я называю доменами. Они направлены на то, чтобы сгруппировать вместе концепции в рамках вашего проекта, которые принадлежат друг другу. Хотя поначалу это может показаться тривиальным, на самом деле все гораздо сложнее, чем вы думаете. Вот почему часть этой серии статей будет посвящена набору правил и практик, которые помогут вам упорядочить ваш код.

Очевидно, я не могу дать вам никакой математической формулы, почти все зависит от конкретного проекта, над которым вы работаете. Так что не думайте, что эта статья даст фиксированный набор правил. Скорее думайте об этом, как о передаче вам коллекции идей, которые вы можете использовать и развивать, как вам нравится.

Домены и приложения

Если мы группируем идеи вместе, то, очевидно, возникает вопрос: как далеко мы идем? Например, вы можете сгруппировать все, что связано с накладными: модели, контроллеры, ресурсы, правила проверки, задания, …

Это создает проблему в классических HTTP-приложениях: часто не существует однозначного сопоставления между контроллерами и моделями. Конечно, в API REST и для большинства ваших классических контроллеров CRUD может быть строгое взаимно однозначное сопоставление, но, к сожалению, это исключения из правил, которые приведут нас к трудным временам. Например, счета-фактуры просто не обрабатываются изолированно, им нужен клиент для отправки, им нужны заказы для выставления счетов и т. д.

Вот почему нам нужно провести дополнительное различие между тем, что является кодом домена, а что нет.

С одной стороны, есть домен, представляющий всю бизнес — логику; а с другой стороны, у нас есть код, который использует — потребляет-этот домен, чтобы интегрировать его с фреймворком и предоставить его конечному пользователю. Приложения предоставляют конечным пользователям инфраструктуру для удобного использования домена и управления им.

На практике

Так как же это выглядит на практике? Домен будет содержать такие классы, как модели, построители запросов, события домена, правила проверки и многое другое; мы рассмотрим все эти концепции подробно.

Уровень приложений будет содержать одно или несколько приложений. Каждое приложение можно рассматривать как изолированное приложение, которому разрешено использовать весь домен. В общем, приложения не разговаривают друг с другом.

Одним из примеров может быть стандартная панель администратора HTTP, а другим-REST API, также и консоль Laravel Artisan является отдельным приложением.

Если поверхностно посмотреть на проект, то вот как может выглядеть структура папок доменно-ориентированного проекта:

Одна папка для домена на конкретный бизнес концепт
app/Domain/Invoices/
    ├── Actions
    ├── QueryBuilders
    ├── Collections
    ├── DataTransferObjects
    ├── Events
    ├── Exceptions
    ├── Listeners
    ├── Models
    ├── Rules
    └── States

app/Domain/Customers/
    // …

И вот как будет выглядеть прикладной уровень:

Админка
app/App/Admin/
    ├── Controllers
    ├── Middlewares
    ├── Requests
    ├── Resources
    └── ViewModels

REST API
app/App/Api/
    ├── Controllers
    ├── Middlewares
    ├── Requests
    └── Resources

Консоль
app/App/Console/
    └── Commands

По теме пространств имен

Возможно, вы заметили, что приведенный выше пример не соответствует соглашению Laravel \App о том, как использовать корневое пространство имен. Поскольку приложения являются только частью нашего проекта, и поскольку их может быть несколько, нет смысла использовать \App в качестве корня для всего.

Если вы предпочитаете оставаться ближе к структуре Laravel по умолчанию, вам это разрешено. Это означает, что вы в конечном итоге получите пространства имен типа \App\Domain и \App\Api. Но вы вольны делать то, что вам удобно.

Однако если вы хотите разделить корневые пространства имен, вы можете сделать это, сделав небольшое изменение в composer.json:

{
    // …

    "autoload" : {
        "psr-4" : {
            "App\\" : "app/App/",
            "Domain\\" : "app/Domain/",
            "Support\\" : "app/Support/"
        }
    }
}

Обратите внимание, что у меня также есть \Support корневое пространство имен, которое на данный момент Вы можете считать свалкой для всех маленьких хелперов, которым нигде не место.

Какую бы структуру папок вы ни использовали, самое важное, чтобы вы начали думать в группах связанных бизнес-концепций, а не в группах кода с одинаковыми техническими свойствами.

Однако в каждой группе, в каждом домене есть место для структурирования кода таким образом, чтобы его было легко использовать в этих отдельных группах. В первой части этой серии статей будет подробно рассмотрено, как домены могут быть структурированы внутренне и какие шаблоны могут быть использованы, чтобы помочь вам поддерживать вашу кодовую базу в рабочем состоянии по мере ее роста с течением времени. После этого мы рассмотрим уровень приложения, как точно можно использовать домен и как мы улучшаем существующие концепции Laravel, используя, например, модели представлений.

Нам предстоит многое сделать, и я надеюсь, что вы сможете извлечь из этого много полезного для себя и сразу же применить на практике.

Оригинал