пʼятниця, 5 листопада 2010 р.

3 Рівнева архітектура.

Ця стаття з сайту , Хабрахабр

Я її продублював щоб не пропала така хороша річ.

Взаимодействие звеньев и их изоляция. Часть 2

Продолжение статьи «Взаимодействие звеньев и их изоляция.» часть 1

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

Распределение ролей



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

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


Роль слоя хранения данных


  1. Создание представлений, по требованию разработчика в роле слоя бизнес-логики.
  2. Создание хранимых процедур для создания, удаления и обновления данных.
  3. Обработка и оптимизация представлений и SQL в соответствии с планом оптимизации, управления индексами и т.д.

Роль слоя бизнес-логики


  1. Создание и внедрение внешних интерфейсов, необходимых слою представления, с помощью веб-сервисов или других средств удаленного взаимодействия.
  2. Определение внешних интерфейсов, используемых слоем представления.
  3. Формирование требований к представлению данных и хранимым процедурам слоя хранения данных.
  4. Реализация всех преобразований данных между виртуальным и физическим слоем.
  5. Создание первичных регрессивных тестов для построения и тестирования слоя бизнес-логики.

Роль слоя представления


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

Передача ролей



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

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

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

Следующий рисунок демонстрирует пример правильного распределения ролей.



Следующий рисунок показывает неверное распределение ролей. И Джо, и Адам работают в разных ролях в пределах одного модуля. Такие нарушения приводят к тесной связи и потере изолированности между слоями.



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



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

Малые команды



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

Сверхмалые команды и одиночки



У сверхмалых команд и одиночек нет другого выбора, кроме как работать в разных ролях в пределах одного модуля. Разработчикам требуется оставаться в пределах слоя и совершать четкие перемещения между ними.

Типичный метод – завершить один модуль и перейти к следующему, когда предыдущий завершен. Допустим следующий подход:


Тем не менее, 2/3 перемещений разработчик будет совершать в горизонтали. Если что-то пошло не так, будет преобладать тенденция сделать шаг назад, создать компромиссное решение и вернуться:


Может оказаться полезным завершать слой за слоем, а не модуль за модулем. Так мы изолируем слои друг от друга. Такой подход, однако, не всегда возможен и требует завершить проектирование заранее. К тому же, некоторым разработчикам может показаться неудобным и сложным скакать между модулями, а не перемещаться последовательно по слоям:


Обратите внимание, что при таком подходе происходит только два горизонтальных шага:


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

Немає коментарів: