Хочу разобраться и обсудить, насколько выгодна «Доменная модель» (Domain Model) архитектуры WEB-приложений (в частности PHP), с различной точки зрения. Какие вы видите в ней недостатки, приемущества и что можно ей противопоставить.
Бизнес-объект (Business Object), это такой объект в ООП, который представляют некую сущность из определенного «домена», то есть отрасли, для которой разработано приложение. Например для бухгалтерской программы объекты могут быть:
Обычно бизнес-объекты инкапсулируют данные и сложную логику, так что интерфейс класса практически отражает реальность. Такой подход к программированию ещё называют «Доменной моделью» (Domain Model), и в противоложность ей существует ORM парадигма и Database-centric архитектура и вцелом подход к разработке архитектуры, основанный на какой-либо технологии, а не на бизнес-модели.
Почему я использую Domain Model и не использую Database-centric архитектуру и подобный подход?
Особенно на «самом верхнем уровне». На уровне методов никакой разницы нет, обычно отдельный метод бизнес-объекта представляет собой довольно сложную логику, например проведение платежа или установки ставки аукциона, однако даже в этом случае нет нужды держать в голове что-то, кроме конкретной проблемы (структуру базы, интерфейс платежной системы).
В приложении (в контроллерах) же всё выглядит наглядно и читается почти по-человечески:
$payment = Payment::makeNew($contractor, $amount);
$invoice = $contractor->lastInvoice();
$invoice->markSettled($payment);
Кому это нужно? Прдставьте, что после 2-3х месяцев вам понадобилось внести изменения, или обнаружился баг. Пользователь ведь не скажет вам «у меня баг в методе, который отвечает за платежи. скорее всего это связано с базой данных». нет, он скажет «у меня не проходит платёж». И вы знаете где искать проблему (по крайней мере с чего начать — с контроллера). А если он (пользователь) скажет: «у меня суммы в счетах округляется неправильно» вы опять знаете куда идти — в контроллер не нужно — дело в методе, отвечающим за «total».
Особенно это выгодно, когда приходит новый человек на проект.
Конечно, здесь есть нюанс — повторное использование может быть лишь в случае, когда разрабатывается новое приложение из того же «домена». Например, правильно разработанный класс Invoice вряд ли нужно будет сильно изменять в новом приложении. Конечно, то же самое актуально и для других подходов. Возможно даже в более полной мере, однако, если удачно разработаны «утилитарные» классы, такие как Profile, Form, Page разработаны с «Доменной моделью» (в данном случае «доменом» является «WEB, Server Side Application»), их повторное использование тоже будет почти 100% и не будет зависеть от основного, бизнес-домена.
Код получается удивительно «неконфликтным», как с точки зрения языка программирования, так и с точки зрения программиста как человека. При условии, что все компоненты основываются на Bussness Model. Если, например, понадобиться «скрестить» аукцион и магазин, то класс Payment у них останется общим, а класс Product, скорее всего, станет «лотом» для аукциона. Прификсы классов нужны лишь в случае, когда требуется создать специфичный класс, допустим FastshopProduct, при этом связанные классы по-прежнему будут принимать объект такого класса в качесвте параметра, если он наследует Product и взаимодействовать с ним.
Проблема здесь возникает, когда нужно использовать сторонний код. И чаще всего приходиться модифицировать сторонник классы, чтобы всё было «ровно».
Действительно, если классы, методы и переменные названы «по-человечески», а не как-то «user_data», редко нужно прибегать к коментариям в коде. И вообще, я стараюсь не перегружать код лишними комментариями. Если метод возвращает объект класса Profile, незачем писать «метод возвращает профайл» — это итак видно.
Если очень нужно — можно сгенерировать документацию на основе кода. Причем в ней, опять же, новичек сможет быстрее разобраться, потому что ему не будут «мелькать перед глазами» различные BaseObject, BaseDbRow, user_data и всё такое. Зная, о чём проект («домен» проекта) программисту легче вникнуть в абстракцию.
Конечно, есть, как говориться, в этой бочке и ложка. Если каждый объект инкапсулирует всё в себе, включая данные (а это главная отличительная черта данной модели), то при выводе, допустим, результатов поиска, каждый объект читает себя из БД самостоятельно, в результате на странице, в зависимости от ситуации, может быть сотня и больше запросов. Лично я не вижу в этом трагедии, с этим, конечного же, нужно что-то делать. Несложное кэширование позволяет ускорить всё на порядок.
Бизнес-объект (Business Object), это такой объект в ООП, который представляют некую сущность из определенного «домена», то есть отрасли, для которой разработано приложение. Например для бухгалтерской программы объекты могут быть:
- счет-фактура (Invoice)
- платёж (Payment)
- контрагент (Contractor)
- проводка (Posting)
Обычно бизнес-объекты инкапсулируют данные и сложную логику, так что интерфейс класса практически отражает реальность. Такой подход к программированию ещё называют «Доменной моделью» (Domain Model), и в противоложность ей существует ORM парадигма и Database-centric архитектура и вцелом подход к разработке архитектуры, основанный на какой-либо технологии, а не на бизнес-модели.
Почему я использую Domain Model и не использую Database-centric архитектуру и подобный подход?
Код гораздо понятнее
Особенно на «самом верхнем уровне». На уровне методов никакой разницы нет, обычно отдельный метод бизнес-объекта представляет собой довольно сложную логику, например проведение платежа или установки ставки аукциона, однако даже в этом случае нет нужды держать в голове что-то, кроме конкретной проблемы (структуру базы, интерфейс платежной системы).
В приложении (в контроллерах) же всё выглядит наглядно и читается почти по-человечески:
$payment = Payment::makeNew($contractor, $amount);
$invoice = $contractor->lastInvoice();
$invoice->markSettled($payment);
Кому это нужно? Прдставьте, что после 2-3х месяцев вам понадобилось внести изменения, или обнаружился баг. Пользователь ведь не скажет вам «у меня баг в методе, который отвечает за платежи. скорее всего это связано с базой данных». нет, он скажет «у меня не проходит платёж». И вы знаете где искать проблему (по крайней мере с чего начать — с контроллера). А если он (пользователь) скажет: «у меня суммы в счетах округляется неправильно» вы опять знаете куда идти — в контроллер не нужно — дело в методе, отвечающим за «total».
Особенно это выгодно, когда приходит новый человек на проект.
Повторное использование кода
Конечно, здесь есть нюанс — повторное использование может быть лишь в случае, когда разрабатывается новое приложение из того же «домена». Например, правильно разработанный класс Invoice вряд ли нужно будет сильно изменять в новом приложении. Конечно, то же самое актуально и для других подходов. Возможно даже в более полной мере, однако, если удачно разработаны «утилитарные» классы, такие как Profile, Form, Page разработаны с «Доменной моделью» (в данном случае «доменом» является «WEB, Server Side Application»), их повторное использование тоже будет почти 100% и не будет зависеть от основного, бизнес-домена.
Нет конфликтов
Код получается удивительно «неконфликтным», как с точки зрения языка программирования, так и с точки зрения программиста как человека. При условии, что все компоненты основываются на Bussness Model. Если, например, понадобиться «скрестить» аукцион и магазин, то класс Payment у них останется общим, а класс Product, скорее всего, станет «лотом» для аукциона. Прификсы классов нужны лишь в случае, когда требуется создать специфичный класс, допустим FastshopProduct, при этом связанные классы по-прежнему будут принимать объект такого класса в качесвте параметра, если он наследует Product и взаимодействовать с ним.
Проблема здесь возникает, когда нужно использовать сторонний код. И чаще всего приходиться модифицировать сторонник классы, чтобы всё было «ровно».
Код само-документируется
Действительно, если классы, методы и переменные названы «по-человечески», а не как-то «user_data», редко нужно прибегать к коментариям в коде. И вообще, я стараюсь не перегружать код лишними комментариями. Если метод возвращает объект класса Profile, незачем писать «метод возвращает профайл» — это итак видно.
Если очень нужно — можно сгенерировать документацию на основе кода. Причем в ней, опять же, новичек сможет быстрее разобраться, потому что ему не будут «мелькать перед глазами» различные BaseObject, BaseDbRow, user_data и всё такое. Зная, о чём проект («домен» проекта) программисту легче вникнуть в абстракцию.
Конечно, есть, как говориться, в этой бочке и ложка. Если каждый объект инкапсулирует всё в себе, включая данные (а это главная отличительная черта данной модели), то при выводе, допустим, результатов поиска, каждый объект читает себя из БД самостоятельно, в результате на странице, в зависимости от ситуации, может быть сотня и больше запросов. Лично я не вижу в этом трагедии, с этим, конечного же, нужно что-то делать. Несложное кэширование позволяет ускорить всё на порядок.
