Продолжение статьи «Взаимодействие ссылок и их изоляция».
часть 1 Я хотел бы извиниться перед общественностью за то, что разбил статью на две части.
Но в последнее время Хабр перестал принимать большие тексты.
Если кто-то подскажет, как бороться с этой напастью, буду благодарен.
Распределение ролей Старые привычки отмирают с трудом, поэтому многим командам будет трудно перейти к изолированному подходу.
Для реализации подхода «песочницы» хорошо подходит назначение ролей.
Кроме того, дополнительные преимущества будут получены от распределения ролей, в т.ч.
более быстрая и качественная разработка.
Чтобы не допустить некорректного распределения работы по ссылкам, разработчики привязываются к определенному слою.
Работа над конкретным слоем называется ролью.
Роль уровня хранения
- Создание представлений по желанию разработчика как слоя бизнес-логики.
- Создавайте хранимые процедуры для создания, удаления и обновления данных.
- Обработка и оптимизация представлений и SQL в соответствии с планом оптимизации, управлением индексами и т. д.
Роль уровня бизнес-логики
- Создайте и реализуйте внешние интерфейсы, необходимые для уровня представления, с помощью веб-сервисов или других инструментов удаленного взаимодействия.
- Определите внешние интерфейсы, используемые уровнем представления.
- Формирование требований к представлению данных и хранимым процедурам уровня хранения данных.
- Реализация всех преобразований данных между виртуальным и физическим уровнями.
- Создание первичных регрессионных тестов для построения и тестирования уровня бизнес-логики.
Роль уровня представления
- Реализация пользовательского интерфейса
- Подключение пользовательского интерфейса к уровню бизнес-логики с использованием интерфейсов, предоставляемых ролью уровня бизнес-логики.
- Разработка и предложение виртуальных наборов данных или другого контракта на передачу данных на уровень бизнес-логики.
Передача ролей
Хотя разработчики должны быть привязаны к определенной роли, у них должна быть возможность мигрировать между разными ролями.В небольших командах делегирование ролей может позволить лучше распределять ресурсы.
Передача ролей в больших командах позволит разработчикам понять всю систему, осознать влияние своих разработок на реализацию соседних звеньев и защитить систему от влияния отдельного разработчика, который заболеет или уйдет из компании.
Передача ролей, однако, не должна осуществляться произвольно и требует контроля.
Разработчики должны брать на себя определенные роли в определенное время.
По возможности разработчик не должен брать на себя более одной роли в одном модуле.
Если в системе имеется модуль «Покупатель», каждому разработчику не следует назначать более одной роли в модуле «Покупатель».
Однако если разработчик работает над уровнем бизнес-логики в модуле «Покупатель», а затем переключается на разработку уровня представления в модуле «Поставщик», это приемлемо и позволяет более эффективно распределять ресурсы.
На следующем рисунке показан пример правильного распределения ролей.
На следующем рисунке показано неправильное распределение ролей.
И Джо, и Адам работают в разных ролях в одном модуле.
Такие нарушения приводят к тесной связи и потере изоляции между слоями.
Предыдущий пример очень прост в описании и использует только одного разработчика для каждого модуля и ссылки.
Однако этот случай довольно редкий, и в действительности нагрузку разделяют многие разработчики.
Однако до тех пор, пока ни один разработчик не перемещается между ссылками внутри одного и того же модуля, принцип соблюдается.
В этих примерах Petya разрабатывает исключительно уровень хранения данных.
Это не обязательно, и на самом деле Петя может работать и на других слоях.
Другие разработчики также могут работать над уровнем хранения данных.
Но обычно уровень хранения данных обрабатывается администратором базы данных и только администратором базы данных, что я и изобразил.
Маленькие команды
В небольших командах назначение одной роли одному разработчику приведет к ограничению ресурсов.В небольших командах разработчикам приходится чаще менять роли, потому что.
Роль может перейти в неактивное состояние после завершения необходимых элементов.
Хотя смена ролей происходит чаще, тем не менее ее необходимо контролировать.
Смена ролей должна быть четкой и происходить только в том случае, если в этой роли больше нет работы.
Сверхмаленькие команды и отдельные лица
У сверхмаленьких команд и отдельных лиц нет другого выбора, кроме как работать в разных ролях в рамках одного модуля.Разработчикам необходимо оставаться внутри слоев и совершать четкие перемещения между ними.
Типичный метод — завершить один модуль и перейти к следующему после завершения предыдущего.
Давайте воспользуемся следующим подходом: 
Однако 2/3 движений разработчик будет совершать горизонтально.
Если что-то пойдет не так, преобладающей тенденцией будет сделать шаг назад, найти компромиссное решение и вернуться: 
Возможно, будет полезно выполнять работу слой за слоем, а не модуль за модулем.
Таким образом мы изолируем слои друг от друга.
Однако такой подход не всегда возможен и требует предварительного завершения проектирования.
Кроме того, некоторым разработчикам может быть неудобно и сложно переключаться между модулями вместо последовательного перемещения по слоям: 
Обратите внимание, что при таком подходе происходят только два горизонтальных шага: 
Если вы используете описанный выше подход, то вместо перемещения между слоями не забывайте перемещаться между модулями.
На следующем рисунке показан лучший способ: 
Теги: #слои #бизнес-логика #изоляция #дизайн #дизайн и рефакторинг
-
Марс, Органика И Два Стабильных Изотопа
19 Oct, 24 -
Вертолетный Ангар, Управляемый С Самолета
19 Oct, 24 -
Энциклопедия Телевидения Вокруг.тв
19 Oct, 24 -
Sioc Теперь Находится Под Контролем W3C
19 Oct, 24
