Проектирование архитектуры в рамках модели MVC. Часть 1. Бизнес-логика в роли Controller.

После разбора технического задания (ТЗ) от заказчика, системному архитектору отправляются все необходимые документы для последующей разработки составляющих частей приложения, которые удовлетворяют всем требованиями ранее утверждённого ТЗ.

Переходя непосредственно к самой архитектуре, необходимо выделить некоторые уровни проектирования. В первую очередь, здесь необходимо составить грамотное взаимодействие всех компонентов системы со всеми запрошенными требованиями со стороны заказчика. Чтобы это всё реализовать, применяется метод разделения сложной структуры на определённые урони, по возможности, малозависимые друг от друга. Это всё делается для своеобразной мобильности приложения. Ведь намного проще составлять свой дом по кирпичикам, чем просто кидать их в кучу, в надежде на образование какой-то постройки. С появлением уровней в архитектуре проектирования ПО начали появляться некоторые шаблоны «правильного стиля». Их так же ещё называют как паттерны проектирования. Если глубоко не вдаваться в подробности подобных паттернов, можно выделить основные ключевые уровни: представление пользовательского интерфейса, обработка запросов от пользователей с возвратом некоторого результата и хранение пользовательской информации. Данная схема соответствует шаблону проектирования MVC. Как вы можете заметить, перечисленные уровни являются естественными при наличие конечного пользователя-потребителя, для которого и пишется программное обеспечение. Далее уже происходит более структурированный анализ каждого уровня.

Начну обзор с «умного» уровня модели MVC, а именно с бизнес-логики приложения (Controller).

Что значит понятие бизнес-логика? В основном это есть исходный код, который отвечает главным функциональным возможностям всего приложения. То есть, это своеобразная «начинка» всех доступных возможностей программного продукта для конечного пользователя. Так как модель MVC соответствует стандартам ООП, то бизнес-логика, в нашем примере, основывается на разработке определённых классов и соответствующих связей между ними. Но не была бы так сложна профессия архитектора ПО, если бы проектирование подобных классов программы являлось простым занятием.

Всё достаточно сложно, ведь одному человеку нужно продумать до мелочей следующие важные вопросы:

  1. Какие уровни бизнес-логики нужно выявить перед началом проектирования всех классов.
  2. Как продумать построение составленных уровней, их связи и зависимости, либо «независимости».
  3. Как распределить необходимые функционалы приложения по всем уровням.
  4. Какие классы нужно создать для каждого уровня и как их всех логически правильно связать.
  5. Какой набор интерфейсов нужно спроектировать для каждого класса, чтобы он в целом со всеми классами удовлетворял всем вышеприведённым требованиям.

Рассмотрим каждый пункт по-порядку:

В первом уровне мы можем найти в основном следующие уровни: уровень логики отображения информации, уровень логики принятия/обработки информации и уровень логики манипуляций с данным. Как вы, наверное, смогли заметить, это очень даже похоже на нашу первоначальную модель MVC. В чём загвоздка и где разница? Могу вас уверовать в том, что здесь нет никакого подвоха. Всё очень просто — модель шаблона MVC является базой проектирования многих частей разработки ПО. Это как использование математики 2 + 2 = 4, которая реализуется даже в программном обеспечение по прогнозу погоды. То есть, результат математических вычислений (как 2 + 2) являются стандартом правильного использования математических чисел и операций над ними. Так вот и с моделью MVC, потому что это тоже стандарт проектирования и разделения частей программы на необходимые, или я бы даже сказал, требуемые составляющие. Если ПО избегает подобных правил построения, то оно признаётся неправильным продуктом. Так же, как бы если это ПО в сложении 2 + 2 выдавало не 4, а 5.

Думаю, вы скажете, а почему это продукт не использующий модель MVC является неправильным? Если поглубже заглянуть в понятие как продукт, то можно заметить следующие составляющие. Продукт ПО — это некое приложение, которое разработано на продажу (термин «продукт» пришёл из бизнес сферы). Под каждой продажей продукта подразумевается предоставление конечному пользователю некоторого набора функционала в своеобразной обёртке ПО. То есть пользователю неважно, что внутри этого приложения. Главное чтобы оно делало то, что ему надо. Но где же тут причина MVC? Отвечу на этот вопрос, напомнив про техническую и другую поддержку продаваемого ПО, которое, возможно, в ближайшем будущем сломается у пользователя. При поломке программы нужно будет лезть в её «начинку» и искать проблему. И тут к нам приходит на помощь наша модель MVC, с которой мы точно знаем о том, где и какая часть нашего кода ответственна за нерабочий функционал. К примеру, если пользователь жалуется, что у него не происходит сохранение его учётных данных на его компьютеру, то тут можно сразу понять в чём же проблема — а проблема в бизнес логике уровня манипуляции с данными. После чего данная информация об ошибке отправляется именно тем разработчикам, которые отвечают за данный уровень. Подчеркну, что не всем разработчикам, а именно определённым. В чём плюсы? Они в том, что не нужно будет заставлять всех разработчиком всего ПО «ковыряться» во всём коде в поисках незадачливой ошибки. Здесь огромнейшая выгода как в экономии времени исправления ошибки, так и в затратах рабочих часов лишних программистов, когда как часы все эти оплачиваются.

Теперь вернёмся к понятию продукта и сделаем вывод. А вывод о том, что любое ПО может называться продуктом, только если в нём заложена возможность исправления неполадок в «оптимально быстром темпе», что соответствует другим маркетинговым и экономическим моделям развития программного обеспечения. Ещё один немало важным показателем продукта является возможность его модернизации. Если сделать из всех исходных кодов приложения целую кашу, то вряд ли тут можно говорить о какой-либо дальнейшей модернизации. А если нельзя усовершенствовать ПО, то оно слабо может подходить под понятие как продукт. При выполнении всех стандартов MVC, любое программное обеспечение легко поддаётся качественной модернизации.

Переходя ко второму пункту нашего вышеперечисленного списка, хочу сразу же сказать про понятие как мобильность. Что это такое? А это некоторое свойство, за которым скрывается лёгкое, простое и быстрое манипулирование чем-то либо как-то. Понятие мобильности свойственно как к предметной (личностной) области, так и к некому действию. Так вот, второй пункт как раз и рассматривает вопросы необходимости реализации мобильности между уровнями. Если принято решение, что подобное понятие нужно применить к данному уровню, в дальнейшем появляются такие элементы проектирования как модули. В двух слова, модуль можно описать как часть некоторой программы, которая выполняет исключительно индивидуальные задачи, прибегая лишь только к набору своих инструментов. Это как кирпичик в стене, которая отвечает за поддержку всей структуры стены в определённом месте. При разрушении этой постройки и не нарушении целостности кирпичей, можно заново построить стену, положив каждый кирпичик на своё место. Так и в построении ПО. Каждый модуль отвечает за свою работу. А если все модули соединить, то получается целостная «стена» (приложение).

Почему мы выше говорили о мобильности? Потому что в понятие как модуль как раз и заложена данная мобильность. Эти «кирпичики» независимы друг от друга, поэтому их легко обновлять, удалять, либо переносить в другие части (уровни) исходных кодов программы. При всех этих манипуляций с одним модулей никаких ошибок не будет наблюдаться у других, потому что они в некотором роде целостные и самодостаточные. В тех ситуациях, когда один модуль использует функционал другого, и при «разрушении», к примеру, первого из них, во втором закладывается логика правильного реагирования на «отсутствие» нужного модуля, либо на предмет его неисправности. Второй уровень нашего списка как раз и занимается вопросами о работоспособном взаимодействии каждого модуля друг с другом. Как правило, хорошим тоном проектирования ПО является обязательное использование независимых между собой модулей.

Познакомившись с понятие модуля, перейдём к третьему уровню в нашем списке. Распределение необходимого функционала по уровням подразумевает под собой продумывание внутренней логики каждого модуля приложения. То есть тут нельзя допустить, чтобы, к примеру, в модуле по работе с БД был функционал по работе с графическим представлением для конечного пользователя. Это логически разные задачи, поэтому они должны быть разделены по разным модулям. Подобный пример является очень простым, когда как в реальности очень сложно правильно «разложить» весь необходимый функционал по «полочкам». Такое занятие может отнимать очень большое количество времени, а если у человека, который этим занимается, нет хорошего опыта в разработке ПО, то начинаются сплошные «подводные камни». Чтобы правильно спроектировать данный уровень, нужно чётко себе представлять то, как вообще работают подобного типа программы и какие возможные неполадки да ошибки могут поджидать. Это всё очень важно, потому что при неверном проектировании зарывается под корень вся разработка в целом. Собственно говоря, архитектор должен прекрасно уметь представлять себе в уме функциональную часть кода, для правильного создания макета написания этого кода. Добавлю то, что вся работа от архитектора потом передаётся программистам, которые и пишут весь код. В результате получается, что архитектор — это своеобразный программист, который не тратит время на написание необходимых алгоритмов, а сразу уже создаёт обёртку нужного функционала. Начинку же для данной обёртки пишут конкретные кодеры (программисты, которые пишут код).

Получив план о создании необходимых частей и разбора задач, которые выполняются ими, можем перейти к обзору следующего нашего уровня, а именно к четвёртому. Здесь уже рассматривается каждый модуль индивидуально. У нас есть список задач, которые должен выполнять наш модуль. Вот над этим списком мы и работаем. Вспомнив про ООП, мы берём принцип построения классов для разброса по ним всех требований бизнес-логики модуля. Очень важно правильно подобрать количество классов и эффективно разбросать по ним соответствующие задачи. Чтобы суметь всё это правильно сделать, нужен как раз богатый опыт каких-нибудь разработок в роли обычного программиста. Как правило, из-за этого в должности архитектора попадают люди с опытом как минимум от 3-5 лет программирования.

И тут подошло время объяснить, почему я сделал разделение четвёртого уровня на два подуровня. Дело всё в том, что проектирование и составление интерфейсов классов в некоторых случаях является почти что ли не отдельной работой по отношению к созданию классов. Некоторые архитекторы сначала проектируют лишь интерфейсы между собой, а потом их распределяют по классам. Другие же сначала проектируют классы, а потом уже наполняют их соответствующими интерфейсами. Но суть задачи практически одна, лишь подход к её решению разный.

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

Проектирование архитектуры в рамках модели MVC. Часть 1. Бизнес-логика в роли Controller.: 2 комментария

Добавить комментарий

Ваш e-mail не будет опубликован.