Современные веб-приложения уже не получается разрабатывать в рамках MVC(Model View Controller) архитектуры. Все больше и больше бизнес правил, высокие нагрузки и тонны кода. Все это превращается в вязкое болото, вносить изменения становится всё дороже. Ресурсов не хватает, растет стоимость квалифицированных разработчиков.
На помощь приходит Domain Driven Design(DDD) и луковая архитектура(onion architecture).
Domain Driven Design
Domain Driven Design переводится как Предметно-ориентированное проектирование. Предметная область это - то, что делает организация, как она это делает. Это бизнес-логика.
Если кратко, то DDD - набор способов выделения моделей предметных областей.
Основой является Единый язык(ubiquitous language), это мощный инструмент, который позволяет разработчикам общаться с бизнесом на одном языке, не возникает путаницы. Бизнес говорит "Task", разработчик в коде пишет "TaskModel". Бизнес говорит "Bill Request", разработчик пишет "BillRequestHandler". Разработчик говорит что "Bill Request" сломался, и бизнес его понял.
Попробуйте не запутаться когда отдел Доставки и отдел Продаж говорят слово "чек". Каждый говорит про разные сущности, там разные поля, разная логика. Но вы должны это понимать и писать код. А теперь, когда вы написали код, к вам прибегает менеджер и спрашивает как себя код ведет в ситуации Х. Если вы не говорите на едином языке, то абстракции программиста могут очень сильно озадачить менеджера.
У меня был проект, в котором одна сущность называлась тремя разными названиями и каждый раз вызывала непонимание. В коде сущность называлась LeadAlarm, менеджер проектов называл её TODO, а клиент Notification.
Отличный пример Единого языка - 1С: Бухгалтерия. Программисты 1С общаются с бухгалтерами на одном языке. Код пишут тоже на одном языке:)
Еще одним важным инструментом является Ограниченный контекст(bounded context).
В зависимости от контекста значения сущностей могут иметь разное значение.
Например, поле Name в контексте Country значит Название страны, а в контексте User - Имя пользователя.
DDD помогает разделить монолитное приложение на множество контекстов. Поначалу мне было проще понять это, воспринимая, что Контекст = Модуль.
Внезапно приложение становится набором независимых модулей, которые можно сравнительно просто поддерживать.
Вспомните момент, когда вы что-то ищите в своем гараже или кладовке. Вместо громадной коробки с барахлом сваленным в кучу вы получаете упорядоченную систему хранения. Множество небольших коробочек с надписями. Например, коробочка с надписью "Игрушки", "Инструменты", или "Старые фото".
Луковая архитектура
Вся суть архитектуры в разделении слоев. Каждый слой может вызывать только слой после себя(внутрь, к центру). Процесс обработки запроса к приложению похож на снятие луковых слоев. Вы снимаете слой за слоем, не имея возможности сразу увидеть сердцевину луковицы.
Следуя такому правилу будет значительно проще соблюдать чистоту кода и не допустить его превращения в болото.
Итог
Объединив DDD и луковую архитектуру мы получаем очень гибкую и понятную систему, позволяющую сильно упростить понимание и реализацию бизнес-логики.
Минусом этого подхода является время разработки на начальных этапах. Внедрить DDD и луковую архитектуру займет некоторое количество времени. Однако, если проект быстро развивается, то потраченные усилия будут очень скоро компенсированы.
Если вы, как и я, являетесь PHP разработчиком, то можете попробовать данный подход в своем Symfony приложении, как это можно сделать минимальными усилиями я уже писал в своей статье.
Подписывайтесь, ставьте лайки, пишите комментарии