4 типа архитектуры программного обеспечения
Детальный обзор существующих подходов
Зачем нужна архитектура ПО
Первые разработчики создавали программное обеспечение без архитектуры. Сначала это казалось удобным: никаких издержек, связанных с планированием, и ускоренное прототипирование. Но мере усложнения ПО теряло гибкость и управляемость, а каждое новое изменение обходилось все дороже. Это мешало развивать проект за границы, определенные изначально. Такая система получила название Большой комок грязи (Big Ball of Mud).
За годы развития ПО разработчикам удалось придумать надежные подходы, чтобы устранить недостатки проектирования без архитектуры. Ниже представлены некоторые из самых известных.
Подробно рассмотрим каждую из них.
Многослойная архитектура
Этот подход работает п о принципу разделения ответственностей. ПО разделено на слои, лежащие друг на друге, и каждый из них выполняет определенную обязанность.
Архитектура делит ПО на следующие слои.
Данные и элементы управления проходят через каждый слой в дизайне и передаются от одного к другому. Эта система также повышает уровень абстракции и в некоторой степени даже стабильность ПО.
Преимущества
Недостатки
Многоуровневая архитектура
Этот архитектурный подход разделяет комплекс ПО на уровни по принципу взаимодействия “клиент-сервер”. Архитектура может иметь один, два и больше уровней, разделяющих ответственности между поставщиком данных и потребителем.
Этот подход использует шаблон Request Response для связи между уровнями. В отличие от многослойной архитектуры, он предлагает масштабируемость, которая может быть как горизонтальной (масштабирование сети с помощью высокопроизводительных узлов), так и вертикальной (масштабирование каждого узла путем повышения его производительности).
Одноуровневая система
В данном подходе единая система работает как на стороне сервера, так и клиента. Это обеспечивает простоту развертывания и отличную скорость связи, а также устраняет необходимость межсистемного взаимодействия (Inter-system communication — ISC).
Такая система подходит только для небольших однопользовательских приложений.
Двухуровневая система
Эта система состоит из двух физических машин в качестве сервера и клиента. Она обеспечивает изоляцию операций управления данными, обработки данных и операций представления.
Трехуровневая и n-уровневая системы
Такие архитектуры обладают высокой масштабируемостью как по горизонтали, так и по вертикали. Реализация n-уровневой системы, как правило, обходится дороже, но обеспечивает высокую производительность. Поэтому она обычно применяется в крупных и комплексных программных решениях.
Этот подход можно сочетать с современной сервис-ориентированной архитектурой, чтобы создавать сложнейшие модели. Поскольку реализация может оказаться дорогостоящей с точки зрения времени и ресурсов, рекомендуется использовать его для сложных ПО, требующих производительности и масштабируемости.
Сервис-ориентированная архитектура (SOA)
Эта архитектурная модель состоит из компонентов и приложений, которые связываются друг с другом с помощью четко определенных сервисов.
Она состоит из 5 элементов:
Клиент отправляет запрос с использованием стандартного протокола и формата данных по сети. Этот запрос обрабатывается ESB (enterprise service bus — сервисная шина предприятия), которая считается сердцем сервис-ориентированной архитектуры и отвечает за оркестровку и маршрутизацию. С помощью сервисного репозитория ESB направляет запрос в специальный сервис, который может взаимодействовать с другими сервисами и базами данных, чтобы составить полезную нагрузку (данные) ответа.
Полный вызов ответа на запрос согласуется с правилами управления и безопасности SOA для выполнения безопасной и корректной транзакции.
Как правило, сервисы делятся на два вида.
Типы сервисов
Mикросервисная архитектура
При таком подходе приложение разрабатывается как набор небольших сервисов, каждый из которых работает в собственном процессе и связывается с легковесными механизмами, обычно API для HTTP-ресурса.
Архитектура работает по принципу компонентизации сервисов. Она разделяет программное обеспечение на различные изолированные компоненты (сервисы), каждый из которых несет единую ответственность. Изменения в одной сервисе не должны затрагивать другие.
Состав микросервисов
Архитектура состоит из изолированных компактных микросервисов, способных расширяться независимо друг от друга. Она включает 5 следующих компонентов:
Характеристики микросервисов
Микросервисная архитектура должна включать следующие характеристики.
Рекомендуется развивать каждый микросервис отдельно под управлением разных команд. Поскольку передача данных происходит по стандартному протоколу и формату данных, структура одного сервиса не затронет функциональность сопутствующих.
Немного об архитектурах программного обеспечения
Никаких сомнений, что за последнее время мир только укрепил свою зависимость от программного обеспечения. Приложения должны обладать высокой доступностью, качественно выполнять требуемые функции и иметь адекватную стоимость. Эти характеристики, в той или иной степени, определяет архитектура ПО.
В стандарте IEEE 1471 дается следующее определение: «Архитектура – это базовая организация системы, которая описывает связи между компонентами этой системы (и внешней средой), а также определяет принципы её проектирования и развития». Однако многие другие определения архитектуры признают не только структурные элементы, но и их композиции, а также интерфейсы и другие соединительные звенья.
Пока что у нас нет общепринятой классификации архитектурных парадигм, но все-таки мы легко можем выделить несколько базовых и широко распространенных архитектурных паттернов или стилей. Взглянем на некоторые из них.
«Каналы и фильтры» (Pipes and Filters)
Рисунок 1 – Pipes and Filters
Этот вид архитектуры подходит в том случае, если процесс работы приложения распадается на несколько шагов, которые могут выполнятся отдельными обработчиками. Основными компонентами являются «фильтр» (filter) и «канал» (pipe). Иногда дополнительно выделяют «источник данных» (data source) и «потребитель данных» (data sink).
Каждый поток обработки данных – это серия чередующихся фильтров и каналов, начинающаяся источником данных и заканчивающаяся их потребителем. Каналы обеспечивают передачу данных и синхронизацию. Фильтр же принимает на вход данные и обрабатывает их, трансформируя в некое иное представление, а затем передает дальше.
К примеру, один из фильтров может реализовывать шифр Цезаря – шифр подстановки, в котором каждый символ в тексте заменяется символом, находящимся на некотором постоянном числе позиций левее или правее в алфавите. Одна из вариаций кода Цезаря – это ROT13, имеющая шаг равный 13.
Рисунок 2 – Принцип ROT13
Его достаточно просто реализовать с помощью стандартной терминальной утилиты Unix tr:
А вот код на Python:
Фильтры можно легко заменять, использовать повторно, переставлять местами, что дает возможность реализовывать множество функций на основе ограниченного набора компонентов. Более того, активные фильтры могут работать параллельно, что приводит к значительному повышению производительности на многопроцессорных системах. Однако есть и недостатки, например, фильтры зачастую тратят больше времени на преобразование входных данных, чем на их обработку.
В качестве примера использования этой архитектуры может служить оболочка UNIX Shell, одним из дизайнеров которой был Дуглас Макилрой (Douglas McIlroy). Другим примером может стать архитектура компилятора, если рассматривать её как последовательность фильтров: лексера, парсера, семантического анализатора и генератора кода.
Дополнительную информацию по этому типу архитектуры можно найти здесь и здесь.
Многоуровневая архитектура
Является одной из самых известных архитектур, в которой каждый слой выполняет определенную функцию. В зависимости от ваших нужд вы можете реализовать любое количество уровней, но слишком большое их количество приведет к чрезмерному усложнению системы. Часто выделяют три основных уровня: уровень представления, уровень логики и уровень данных.
Рисунок 2 – Многоуровневая архитектура
Слою не обязательно знать, что делают его соседи. Здесь проявляется такое свойство как разделение ответственности. Если все три слоя являются закрытыми, то запрос пользователя к верхнему уровню инициирует цепочку обращений с верхнего уровня до самого нижнего. В этом случае уровень представления отвечает за пользовательский интерфейс и отображение данных для пользователя и ничего не знает о существовании физического хранилища данных. Ничего о существовании базы данных не знает и уровень логики – его «беспокоят» только правила бизнес-логики. Доступ к базе данных имеет лишь через уровень управления данными.
Достоинствами применения такой архитектуры являются простота разработки (в основном из-за того, что этот вид архитектуры всем знаком) и простота тестирования. Среди недостатков можно выделить возможные сложности с производительностью и масштабированием – всему виной необходимость прохождения запросов и данных по всем уровням (опять же, в том случае, если все слои являются закрытыми).
Одним из самых известных примеров этого паттерна может служить сетевая модель OSI. Подробнее о многоуровневой архитектуре можно почитать, например, в блогах вот этих трех программистов и разработчиков:
Архитектура, управляемая событиями (EDA)
Это популярный адаптивный паттерн, широко используемый для создания масштабируемых систем. Чтобы ознакомиться с принципами событийно-ориентированной архитектуры, можете посмотреть вот это видео от Complexity Academy:
Рисунок 3 – Событийно-ориентированная архитектура
Если говорить о программном обеспечении, то в этой схеме существует два варианта событий: инициализирующее событие и событие, на которое реагируют обработчики. Обработчики являются изолированными независимыми компонентами, отвечающими (в идеале) за какую-нибудь одну задачу, и содержат бизнес-логику, необходимую для работы.
Посредник может быть реализован несколькими способами. Самый просто способ – это воспользоваться фреймворками для интеграции Apache Camel, Spring Integration или Mule ESB. Для больших приложений, которым требуется более сложные функции управления, вы можете реализовать посредника, используя концепцию управления бизнес-процессами (например движок jBPL).
Архитектура, управляемая событиями – это относительно сложный паттерн. Причиной тому – его распределенная и асинхронная природа. Вам придется решать проблемы фрагментации сети, обрабатывать ошибки очереди событий и так далее. Плюсами этой архитектуры могут служить высокая производительность, легкость развертки и поразительные возможности масштабирования. Однако возможно усложнение процесса тестирования системы.
Подробнее о событийно-ориентированной архитектуре можно почитать здесь.
Микроядерная архитектура
Паттерн состоит из двух компонентов: основной системы (ядра) и плагинов. Ядро содержит минимум бизнес-логики, но руководит загрузкой, выгрузкой и запуском необходимых плагинов. Таким образом, плагины оказываются несвязанными друг с другом.
Поскольку плагины могут разрабатываться независимо друг от друга, такие системы обладают очень высокой гибкостью и, как следствие, легко тестируются. Производительность приложения, построенного на основе такой архитектуры, напрямую зависит от количества подключенных и активных модулей.
Возможно самым лучшим примером микроядерной архитектуры будет Eclipse IDE. Скачивая Eclipse без надстроек, вы получаете совершенно пустой редактор. Однако с добавлением плагинов пустой редактор начнет превращаться в полезный и легко настраиваемый продукт. Еще один хороший пример – это браузер: дополнительные плагины позволяют расширить его функциональность.
Подробнее о микроядерной архитектуре можно узнать здесь и здесь.
Микросервисная архитектура
Этот тип архитектуры позволяет масштабировать приложения по оси Y «Куба масштабирования» (Scale Cube), описанного в книге «The Art of Scalability» Мартина Эбботта (Martin L. Abbott) и Майкла Фишера (Michael T. Fisher). В этом случае приложение разбивается на множество небольших сервисов, называемых микросервисами. Каждый микросервис включает в себя бизнес-логику и представляет собой совершенно независимый компонент. Сервисы одной системы могут быть написаны на различных языках программирования и общаться друг с другом, используя различные протоколы.
Поскольку каждый микросервис является отдельным проектом, вы можете распределить работу над ними между командами разработчиков, то есть над системой могут одновременно трудиться несколько десятков программистов. Микросервисная архитектура позволяет с легкостью масштабировать приложение – если вам понадобилось внедрить новую функцию (развертывать каждый микросервис можно по отдельности), просто напишите новый сервис, а если какой-то функцией никто не пользуется – отключите сервис.
Подробнее о микросервисных архитектурах вы можете почитать в следующих источниках: здесь, тут и вот тут.
Дополнительные материалы
В рамках этой статьи мы рассмотрели несколько видов архитектур программного обеспечения. Разумеется, здесь не было затронуто множество других паттернов. В качестве дополнительных материалов по теме можете посмотреть следующие ресурсы:
Помимо этого мы рассказываем о работе службы поддержки «облачного» провайдера и теме оптимизации производительности, к обсуждению которой мы планируем вернуться в одном из следующих материалов.
Архитектура ПО: разница между архитектурой и проктированием
Oct 2, 2018 · 6 min read
Определение архитектуры программного обеспечения
Говоря простым языком, архит е ктура программного обеспечения — это процесс превращения таких характеристик программного обеспечения, как: гибкость, масштабируемость, возможность реализации, многократность использования и безопасность — в структурированное решение, которое соответствует как техническим, так и бизнес требованиям. Отсюда возникает следующий вопрос: какие характеристики программного обеспечения могут повлиять на преоктирование архитектуры программного обеспечения? Помимо технических особенностей, также существует множество параметров, которые в основном отвечают требованиям бизнеса или функциональности.
Характеристики архитектуры ПО
Полный список параметров программного обеспечения или так называемых «качественных характеристик» вы найдете здесь.
Архитектурные шаблоны программного обеспечения
Большинство из вас, наверно, уже знакомы с термином « микросервисы». Микросервисы — один из способов моделирования архитектуры ПО, наряду с многоуровневой архитектурой, архитектурой, управляемая событиями, бессерверной архитектурой и многими другими. Некоторые из вышеперечисленных шаблонов будут описаны ниже. Микросервисный стиль архитектуры стал известным после того, как его стали успешно применять в Amazon и Netflix. А теперь, давайте углубимся в детали и более подробно обсудим архитектурные стили.
** Внимание: пожалуйста, не путайте архитектурные стили с шаблонами проектирования, такими как фабричный шаблон проектирования или адаптерами. Я расскажу о них позже.
Бессерверный архитектурный стиль
Этот элемент применим к приложениям, которые в качестве решения используют сервисы третьих лиц для того, чтобы решить проблему загруженности серверов и бэкенда. Бессерверная архитектура делится на две основные категории. Первая это «бэкенд как услуга (BaaS)», вторая — «функция как услуга (FaaS)». Бессерверная архитектура поможет сэкономить время на проверке и исправлении ошибок переноса, а также на работе с регулярными задачами сервера.
Самым известным примером бессерверного API является сервис Amazon AWS «Lambda».
Более подробно прочитать о нем вы можете здесь.
Архитектура, управляемая событиями
Эта архитектура завязана на производителях и потребителях событий. Главная идея состоит в том, чтобы разделить части вашей системы так, чтобы каждая из частей активизировалась, когда интересное событие происходит в другой. Сложно? Давайте упростим. Представьте, что вы создаете систему для онлайн-магазина и она состоит из двух частей: модуль покупок и модуль продаж. Когда клиент совершает покупку, модуль покупок создает событие «orderPending». Так как модуль продаж заинтересован в этом событии, он будет следить за процессом на случай, если его вызовут. Как только модуль продаж получит это событие, он выполнит определенные задания или запустит ещё одно событие для продолжения покупки товаров у определенного вендора.
Запомните, что производитель события не знает за каким из событий наблюдает какой из потребителей события. Также и другие потребители не знают, кто из них за каким событием наблюдает. Таким образом, главная идея заключается в расщеплении частей системы.
Если вы хотите узнать больше про архитектуры, управляемые событиями, перейдите по ссылке.
Архитектура микросервисов
За последние несколько лет архитектура микросервисов стала одной из самых популярных. Она создается на основе небольших, независимых модульных сервисов, каждый из которых решает свою проблему или выполняет уникальное задание. Эти модули взаимодействуют через API, запрограммированный на выполнение определённой бизнес цели. А теперь посмотрите на картинку и вы все поймёте.
Проектирование программного обеспечения
Архитектура — это скелет и многоуровневая инфраструктура программного обеспечения, а проектирование ПО — это проектирование на уровне кода, например: чем занят каждый из модулей, разнообразие классов, цели функций, и т.д.
Если вы разработчик, вам необходимо знать принципы SOLID, и понимать, как шаблон проектирования должен решать повседневные проблемы.
Принципы SOLID ( Single Responsibility, Open Closed, Liskov substitution, Interface Segregation and Dependency Inversion Principles ) — это единственная ответственность, открытость/закрытость, принцип подстановки Барбары Лисков, принцип разделения интерфейсов и принцип инверсии зависимостей.
Шаблоны проектирования
Представим, что вы хотите реализовать модель класса пользователей Users(), — вы можете использовать один из двух методов:
Я бы выбрал второй, по двум основным причинам, помимо всех остальных. Во-первых, изменение названия класса с «Users» на «UserData» — это всего лишь одно изменение в одном месте, внутри фабричной базы, в остальном ваш код остается тем же. Во-вторых, если в классе «Users» появятся такие параметры как Users($connection), то вам останется только внести изменения в одном месте, а не в каждой функции которая использует объекты класса Users. Поэтому, если вы думаете, что первый вариант лучше, подумайте ещё раз.
Представьте,что ваше приложение работает по API c YouTube и, чтобы получить токен доступа, вам необходимо вызвать функцию getYoutubeToken();
Итак, вы вызвали эту функцию в 20 разных местах в приложении.
А потом, Google публикует новую версию API, переименовав функцию на getAccessToken();
Теперь вам придется найти и переименовать эту функцию во всем приложении или создать адаптер-класс, как показано далее в примере:
В последнем случае, единственное, что вам придется сделать — изменить одну строку, все остальное приложение продолжит работать как раньше.
Помните, что архитектор программного обеспечения и разработчик программного обеспечения — две разные вещи. Архитекторы программного обеспечения обычно работают с опытным тимлидом, который хорошо знает существующие решения, что помогает ему принимать правильные решения на стадии планирования. Разработчик программного обеспечения должен знать особенности проектирования программного обеспечения и также обладать знаниями об архитектуре приложения, чтобы команде было легче взаимодействовать.
Как проектируют приложения: разбираемся в архитектуре
Старший iOS-разработчик из «ВКонтакте» рассказывает, почему архитектура не главное в проекте и как сделать продукт поддерживаемым и масштабируемым.
Катя Павловская для Skillbox Media
Евгений Ёлчев
Старший iOS-разработчик во «ВКонтакте». Раньше был фулстеком, бэкендером и DevOps, руководил отделом мобильной разработки, три года преподавал iOS-разработку в GeekBrains, был деканом факультета. Состоит в программном комитете конференции Podlodka iOS Crew, ведёт YouTube-канал с видеоуроками по Flutter. В Twitter пишет под ником @tygeddar.
Я люблю спорить о том, какая архитектура лучше. Может, из-за своего внутреннего перфекциониста или диплома архитектора информационных систем, а может, потому, что мне лень копаться в плохих проектах.
Спойлер: больше всего я люблю архитектуру MVC. Дальше расскажу, как она работает и почему мне не нравятся всякие MVVM, MVP и VIPER. Кстати, недавно я разобрался во Flux и её имплементации Redux и понял, что их я тоже недолюбливаю.
В основе статьи — тред автора в Twitter.
Что такое архитектура MVC
Я тогда был студентом, делал курсовые и пет-проекты. У них была сложная вёрстка и непростая структура БД, но максимально простая логика. Код получался простым, но в целом меня такой подход устраивал.
Мне не приходило в голову, что можно делать не так, как написано в документации к инструментам и в примерах на форумах. Я был счастлив и не забивал голову чепухой.
Я пробовал поменять логику в своём проекте — перенёс её из одного файла в другой, но разницы не заметил. По факту ничего и не изменилось, только код теперь лежал в другом файле.
Изучая дискуссии в интернете и рассуждая самостоятельно, я понял, что «толстая» модель мне не нравится. Пусть лучше модель остаётся базой данных, а контроллер и дальше управляет логикой.
Со временем мои проекты становились всё сложнее, а контроллеры пухлее (правда, не как UIViewController в iOS). Я пробовал с этим бороться, выносил логику в сторонние файлы, которые включал в контроллеры, но это мало что меняло: архитектура сохранялась, просто код переносился из одного файла в другой.
Почему MVC не работала в моих проектах
В 2013 году я пересел на Laravel, разобрался с автозагрузкой классов в PHP, начал разбираться с ООП и прочитал «Совершенный код» Стива Макконнелла.
Стало ясно, что не стоит складывать всё в один файл — код и классы должны организовывать структуру, а некоторые фрагменты кода лучше убрать из MVC и выделить в самостоятельные части, которые можно переиспользовать.
С этого момента я начал писать проекты по-другому. В них появились иерархии классов, которые хранили логику, а контроллер сильно похудел — он получал данные от базы, передавал их в разные пакеты, получал от них результат и отправлял на HTML-страницу.
Архитектура проектов не была идеальной, потому что не подошла бы ни для одной сложной системы. Но для моих целей она была крутой и удобной: код получался читабельный, а все элементы проекта оставались довольно независимы.
Как я делал систему управления
VDS-сервером
В сложной системе нельзя передавать все данные через один контроллер, поэтому каждый плагин отдельно реализовывал веб- и API-интерфейсы, доступ к данным и бизнес-логику, вынесенную в пакеты для переиспользования.
Получилось так: HTML ⟷ JavaScript (модели, общение с API) ⟷ API ⟷ переиспользуемые пакеты ⟷ бизнес-логика и доступ к данным. Всё это не было похоже на MVC.
Почему архитектура не главное в проекте
Когда я увидел, как это реализуют в других компаниях, то осознал несколько важных нюансов.
Архитектура не даёт преимуществ. Ни одна продвинутая архитектура не была лучше того, что я делал в самом начале. За всё время я перепробовал разные подходы и поэтому мог оценить их пользу для проекта. Но между MVC и MVP не было разницы — кроме названий классов и правил вроде тех, когда элементы вызывают друг друга.
Компании понимают архитектуру по-разному. Одни говорят, что используют MVVM, у других то же самое называется MVC. Я видел пять MVVM-систем, и все были разными. Исключение — VIPER, у которой благодаря Егору Толстому есть подробная документация и много примеров. Но даже там были отличия.
Популярная архитектура не значит лучшая. Выбирать архитектуру из-за мейнстримности бесполезно. Кто-то решает использовать MVVM, но одни и те же компоненты кладёт в разные части проекта.
Архитектура не спасёт проект. Сама по себе она не решает проблемы и не гарантирует успеха.
Что же такое MVC на самом деле
Я постоянно изучал архитектуры, читал книги и спорил с коллегами, несколько раз пересматривал идею MVC в языке Smalltalk и несколько раз менял к ней отношение.
В итоге я понял, что MVC — это не три файла, и даже не несколько классов для каждого элемента. Модель — не про данные и не про бизнес-логику, а контроллер давно не нужен, и пора использовать MV.
Приложения с бизнес-логикой и доступом к данным были и до MVC, им не хватало только пользовательского интерфейса. Главная задача MVC — связать UI со всем остальным. Единственная рекомендация от создателя — при надобности создавать для каждой View свой фасад для Model и слушать его через паттерн-наблюдатель.
View — это и есть пользовательский интерфейс, Model — остальное приложение. Задача Controller — не быть прослойкой между V и M, а всего лишь принимать информацию от пользователя.
Принцип MVC — не мешать UI с бизнес-логикой, базой данных и другими частями приложения. А как это реализовать, уже пускай думает архитектор. Это не космическая инженерия.
Важно понимать, что MVP, MVVM или VIPER не заменяют MVC, а только дополняют её. Контроллер уже не нужен, потому что за ввод данных отвечает View, это стало его неотъемлемой частью.
Получается, что MVC в Apple, MVVM и другие варианты — это MV, где контроллер убрали за ненадобностью. Из всех современных MV(x) именно MVVM больше всего похожа на каноническую MVC.
Все эти термины усложняют общение. Иногда сложно понять, о чём тебе говорят, хотя задача архитектуры в том, чтобы всё было проще и понятнее.
Как разобраться в любой архитектуре
Может показаться, что все архитектуры одинаковые, и им вообще не стоит уделять внимания. Но это не так. У меня есть несколько правил.
Главное — реализация. Глобальная архитектура не так важна, как её воплощение. Всё зависит от того, как вы называете классы, где храните элементы и как классы общаются между собой. Все из команды должны соблюдать ваш стандарт, и тогда проект будет проще поддерживать.
Model — ваша ответственность. Архитектура MVC не даёт инструкций, как правильно написать основную часть приложения. Ваша ответственность в том, чтобы не устраивать в Model кашу, где половина классов — Service, а вторая половина — Helper.
Нужно разбираться в основах. Не стоит изучать конкретную архитектуру, лучше понять, из чего она логически следует. Тут поможет история, объектно-ориентированное и функциональное программирование, паттерны, SOLID и всё остальное. Обязательно надо прочитать «Совершенный код» Стива Макконнелла.
С какого-то момента я начал теряться в проекте. У меня появилась куча сущностей с похожими названиями и похожими данными, я создал миллиард экшенов. В итоге сам запутался, что, как и с чем взаимодействует.
Redux хороша для больших проектов, ориентированных на офлайн, где одновременно происходит куча асинхронных неблокируемых событий. Там этот бойлерплейт стоит терпеть, потому что он спасёт вам жизнь. Но в обычном тонком клиенте лучше использовать стандартную MV и не париться.
Вывод: что прочитать об архитектуре
На «Хабре» есть отличные статьи об MVC — «Охота на мифический MVC. Обзор, возвращение к первоисточникам и про то, как анализировать и выводить шаблоны самому» и «Охота на мифический MVC. Построение пользовательского интерфейса». Обязательно прочитайте их, если интересуетесь архитектурой — автор тщательно и на хороших примерах разобрал, что это такое.