Архитектура: Основные понятия

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

Рекомендуется в документации к проекту указывать какая архитектура используется (то же касается и паттернов). Лучше, конечно, выбирать более традиционные архитектуры, без самостоятельных “разработок”.

Основной функционал

К этому виду кода следует относить те участки, которые несут некую функциональность, выполняют технические задачи. Например:

Layer
Objects factory
Repository
Value Object
View
ViewModels

Концептуальные объекты

Все что относится к основной области приложения - те объекты, которыми приложение будет оперировать. Например:

User
Product
Checkout
Order
Delivery
Bill

Любой объект может исполнять роль основного функционала и являться концептуальным объектом.

Пакеты

В терминологии Java - набор классов (и прочих элементов языка), объединенных в группу.

Модули

Крупное объединение пакетов в большую группу, выполняющую (купную) функциональную задачу. Например, это может быть модуль безопасности, модуль взаимодействия по протоколу безопасности и т.п.

Компонент

Пакет, входящий в основную область приложения, являющийся неотъемлемой частью бизнеса-функционала. Например, компонентами могут являться пользователь (user), продукты (product). Являясь пакетом (элементами языка, объединенными в группы), компоненты могут содержать в себе реализации концептуальных ообъектов, например: пользователи - User, UserCredentials, UserContact; продукты - ProductVariant, ProductStock, ProductGroup.

Приложение

Приложение - это полный комплекс сервисов, реализаций графических интерфейсов, консольных утилит и прочего, что так или иначе требуется (включая и опциональные) для работы приложения.
Так, например, консольная утилита, web и мобильное приложение пользователей, web и мобильное приложение администраторов системы, микросервисы для работы с внешними системами и прочее - все это является составными частями одного приложения!

Система

Включает в себя все части приложения, но дополняется различными средствами (часто сторонними), которые так же необходимы (или желательны) для функционирования приложения. Например, это могут быть (неотъемлемые) средства администрирования, внешние сервисы, предоставляющие данные для приложения.

Архитектура

Выбранный способ организации системы. Довольно редко (и болезненно) подвергающийся измеениям. Существует некоторый набор типовых архитектур, но довольно часто (крупные) компании могут подстраивать их под свои нужды - тем самым создавая новые тенденции и тренды по реализации архитектуры.

Признаки плохой архитектуры

Закостенелость. Влечет за собой очень тяжелые переходы к новым подходам к реализации различных функций.

Хрупкость. Обратная сторона предыдущего признака - архитектура может быть слишком нестабильной. Это еще одна причина почему выбор традиционной архитектуры (с незначительными модификациями) не такой уж плохой!

Низкая партисипация. Проблема в сложности изъятия части приложения. Это может потребоваться, например, в связи с устарением функциональной необъходимости или в связи с необходимостью использования части реализации в других приложениях (или, даже, системах).

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

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

Непрозрачность. Архитектура системы может быть очень запустанной - это затруднит дальнейшую ее модификацию.

Избыточность. Довольно часто применная архитектура может быть избыточна для тех функций, которые должна реализовать система.

Классические архитектуры

Как отмечалось ранее, вариаций арихитектур довольно много, они постоянно пополняются надстройками и кастомизациями. Тем не менее, существует некоторый набор “классических” архитектур, которые следует знать. Некоторые из них рассматриваются отдельно:

Специфические паттерны

Entity-Boundary-Interactor (EBI)

Архиттектурные паттерны

Multitier architecture
Model–view–controller
Domain-driven design
Blackboard pattern
Sensor–controller–actuator
Presentation–abstraction–control
Component-based
Monolithic application
Layered
Pipes and filters
Database-centric
Blackboard
Rule-based
Event-driven aka implicit invocation
Publish-subscribe
Asynchronous messaging
Microkernel
Reflection
Client-server (multitier architecture exhibits this style)
Shared nothing architecture
Space-based architecture
Object request broker
Peer-to-peer
Representational state transfer (REST)
Service-oriented
Cloud computing patterns