Component Based Architecture
Переосмысливание архитектуры
Preface
Предисловие: Почти каждое приложение, платформа, онлайн-учебник, все в эти дни крутится вокруг идеи многоуровневой архитектуры, где у нас есть контроллеры, сервис и слои моделей данных.
Мы склонны слепо применять шаблон дизайна или стиль кода, не понимая причин этого принципа дизайна или его компромиссов-Cargo cult programming .
Мы думаем, что мы должны сделать это, потому что так делают все остальные. Это шумиха и мода. Это лучшая практика. Он имеет много upvotes на StackOverflow.
В результате мы имитируем, а не думаем.
Мы принимаем плохие, неосведомленные решения вместо того, чтобы добавлять ценность.
Мы склоняемся к тому, что раскручивается. В конце концов, машинное обучение не сделает из нас лучших инженеров-программистов.
Найти кого-то, кто может говорить о программной инженерии в эти дни, — все равно что пытаться найти иглу посреди стога сена.
Дизайн архитектуры программного обеспечения считается концептуальной вещью, кучей коробок и линий, но это структура, и путь,который мы проделываем, чтобы добраться до этой структуры и передать ее.
Команды борются, чтобы передать дизайн программного обеспечения. Это сложно, слишком подробно, страшно и т.д. Мы не знаем, как выразить идеи, уровень детализации и обозначения. Нам не хватает понимания основополагающих принципов проектирования.
Редко можно найти кого-то, кто знаком с UML. Ведь они не актуальны для рынка по сравнению с тем, кто делает Kubernetess.
И хотя цель проектных документов состоит в том, чтобы служить исходным материалом для реализации и облегчить сообщение о программном коде, они в конечном итоге не отражают код.
Реализовали ли мы код так, как его разработали? Нет. Код не отражает архитектуру, эти абстракции. На самом деле, никто не смотрит на схемы архитектуры в любом случае. Почему?
- Они устарели.
- Они не могут обращаться или не обращаются.
- Они не соответствуют коду.
- Это просто куча блоков.
4 из наиболее распространенных архитектур проектирования будут рассмотрены ниже, выделяя компонентную архитектуру.
Layered architecture
Многоуровневая архитектура: Пожалуй, данный вид наиболее широко используется, используется везде. Почти все приложения построены вокруг него. Его легко понять и легко освоить.
В этом шаблоне мы организуем все в горизонтальные срезы. Количество слоев может отличаться от одного приложения к другому. Вообще, мы имеем:
- Веб-слой: обрабатывает входящие запросы, визуализирует HTML и т.д.).
- Бизнес-уровень: применение бизнес-правил к данным (клиент не может снять деньги с пустого счета)
- Уровень данных: подключается к базе данных для запроса и обновления данных. Они часто называются объектами доступа к данным (DAO).
Когда приходит запрос, он идет сверху вниз.
Но Почему? разделение забот, разъединение, или, может быть, потому, что нам сказали, что это хорошо.
Ну, может быть. Но вопрос в том, отражают ли схемы архитектуры код?. Мы думаем о компонентах, но пишем многоуровневую архитектуру. Эти компоненты не существуют в коде, и язык программирования не имеет ключевого слова layer или component.
И каждый слой вызывает только нижний слой или может пропустить? Каждый слой остается хорошим и чистым?. Controller иногда вызывает модель, и модель перезванивает службы, вызовы повсюду, так как они являются общедоступными.
Ограничения, которые мы указываем в документации или сообщаем разработчикам, не могут быть применены. Мы могли бы пройти через обзоры кода. Но, мы все люди, и чтобы добиться цели быстрее, мы можем быть вынуждены или искушены принять плохой код.
Ports and adapters architecture
Архитектура портов и адаптеров: Луковая архитектура и гексагональная архитектура основаны на идее отделения доменных объектов от их реализации.
В то время как в слоистой архитектуре каждый слой связан со слоями под ним, что означает, что небольшое изменение приведет к изменению во всех слоях, это не совсем так.
Да, у нас есть слои, но внутренние слои являются абстракциями, в то время как другие слои являются фактической реализацией.
Например, внутри пакета order domain у нас есть Ordersинтерфейс, который определяет поля (id, дата, клиент) и поведение (create, update, etc). Все они абстрактны, без реализации.
Кроме того, у нас также естьOrderService, который определяет реализацию вариантов использования и бизнес-правил вокруг них. Эти правила могут быть placeOrder(), cancelOrder(), etc
Все, что находится внутри пакета order domain, не зависит от внешнего мира. Итак, мы можем иметь разные классы, скажемMySQLOrdersRepository, JDBCOrdersRepository, etc, которые реализуют Order. OrderНужно ли знать кому об этих занятиях? Нет.
Контроллер, вызывающий уровень сервиса, передает одну из реализаций порядка, с помощью которой уровень сервиса будет использовать доступ к базе данных и применять бизнес-правила.
private OrderService orderService
= новый OrderService (новый JDBCOrdersRepository())Эта развязка дает преимущество добавления или удаления реализации (адаптеров) без необходимости изменения базовых абстракций (портов).
Тем не менее, может быть трудно иметь 1–1 соответствие с диаграммами проектирования, если они все о компонентах.
Feature-based architecture
Функциональная архитектура: В этом шаблоне мы организуем код на основе того, что он делает с функциональной точки зрения. Это вертикальная нарезка. Мы группируем вместе код, связанный с определенной функцией.
Только контроллер подвергается воздействию внешнего мира. Все остальное защищено пакетом: не может быть вызвано извне пакета функций.
Он имеет более высокую сплоченность, так как весь код находится в одном месте. И если объект рассматривается как компонент, то мы можем легко сопоставить между кодом и схемами проектирования, поскольку код теперь отражает дизайн архитектуры.
Но что делать, если класс обслуживания должен вызвать другой класс обслуживания?
Component-based architecture
Компонентная архитектура: Гибридный подход между многоуровневой и объектной архитектурой.
Вместо многоуровневого подхода, горизонтальных срезов, мы разделяем приложение по вертикали на модульные компоненты, так же, как мы сделали с архитектурой на основе функций.
Компонент в этом контексте-это группа связанных функций, которые находятся за красивым и чистым интерфейсом.
Несколько заметок:
- Контроллер является частью компонента . Хотя мы можем разделить контроллеры (маршрутизаторы) от кода, связанного с компонентом, чтобы отделить обработку HTTP-запросов от самого компонента. Кстати, не каждый компонент нуждается в контроллере в качестве почтового сервиса.
- Компоненты могут общаться друг с другом через интерфейс, в отличие от архитектуры на основе функций, где классы обслуживания скрыты, и единственный способ связи-через контроллер.
Преимущества?
Теперь мы выровняли архитектурное представление мира и представление кода . Это делает код легким для понимания и обсуждения, потому что мы можем вернуться к коду.
Развязка, которую мы получили, заключается в том, что никто не позволяет подталкивать код компонента из внешнего мира, кроме как через его интерфейс.
Каждый компонент инкапсулирован в свой собственный пакет. Он имеет все детали реализации, такие как доступ к базе данных, в отличие от архитектуры портов и адаптеров, где реализация отделена от абстракции.
В компонентной архитектуре мы можем иметь многоуровневую архитектуру, обернутую внутри компонента . Например, платежный сервис (компонент) может иметь три класса: контроллер, сервис и слои модели. В этом случае многоуровневая архитектура не о структуре это скорее деталь реализации.
Эта гибкость между компонентами действительно важна, так как им не нужно знать о внутренней работе друг друга. Компоненты просто взаимодействуют через свои интерфейсы.
Это основная концепция дизайна микрослужб. Позже, при необходимости, становится проще перейти на архитектуру микросервисов.
В конце концов, эти принципы проектирования и шаблоны все о дизайн-мышлении и модульности. Хорошая архитектура предоставляет гибкость: возможность расширяться и изменяться в ответ на изменение требований.
Если вы страдаете от монолитного применения, это, возможно, потому, что вы не смогли разработать модульный монолит. И таким образом, микросервисы в конечном итоге тоже будут грязными. Суть в том, что если архитектура компонентов сложна, мы не можем делать микросервисы, потому что они основаны на одном и том же принципе.
Выберите микросервисы, если они дают вам выгоду не потому, что monolthic грязно. В большинстве стартапов приоритет номер один-двигаться быстро. Расходование денег и усилий на создание микросервисов значительно ускорит прогресс.
Кто его использует?
Я не знаю.
А, точно, React. Это библиотека JavaScript на основе компонентов для построения пользовательского интерфейса.
Кто-нибудь еще? …
C4 Model
Модель C4: Модель C4 представляет собой формализованный подход, используемый для визуализации архитектуры программного обеспечения, основанной на идее компонентов.
Программное обеспечение системы состоит из одного или нескольких контейнеров (веб-приложений, мобильных приложений, настольных приложений, баз данных, файловых систем и т. д.), каждый из которых содержит один или несколько компонентов, которые, в свою очередь, реализуются с помощью одного или более элементов кода (например, классы, интерфейсы, объекты, функции и т. д.) — Источник.
Нет никакой принудительной нотации, но наличие общего и последовательного набора нотаций играет большую роль в понимании и передаче этих диаграмм.
И поскольку эта модель разбивает архитектуру на уровни детализации по мере перехода от контекста (уровень 1) к коду (Уровень 4), она напоминает наличие карты. Мы могли бы увеличить и уменьшить масштаб, чтобы просмотреть всю картину или копать глубже.
Кроме того, это позволяет легко принимать его и создавать другие модели, такие как диаграммы развертывания ; как контейнеры, сопоставленные с инфраструктурой. Это полезно, Так как нам нужно иметь разные взгляды, так как трудно показать весь дизайн в одной картине.
Summary
Итог: Нам нужно разобраться. Что нам нужно? Что работает лучше всего? Мы не должны слепо применять одну и ту же концепцию снова и снова только потому, что все люди делают это. Декомпозиция никогда не является новой темой, и существуют различные способы декомпозиции. Таким образом, это требует усилий и мышления.
Однако одним из ключевых атрибутов является гибкость . Имея хорошую архитектуру, должно быть легко масштабировать и настраивать.
Еще один атрибут-публичность . Если все в приведенных выше шаблонах является “общедоступным”, не будет никакой разницы, кроме только структуры папок.
И, наконец, … это не идет без слов,
Спасибо за чтение!
Translated: medium
Help us with your claps :)
