Изучение архитектуры внешнего интерфейса: обзор некоторых принципов, связанных с чистой архитектурой внешнего интерфейса (SOLID, KISS, DRY, DDD и др.).
В одном из моих предыдущих постов я говорил о Сигналах и о том, чего еще не хватает [1]. Теперь я хочу поговорить о более общей теме, а именно об чистой архитектуре внешнего интерфейса. На эту тему есть много принципов:
SOLID, KISS (будьте краткими и простыми), DRY (не повторяйтесь), DDD (Domain-Driven-Design) и так далее.
В этом посте я расскажу о некоторых из этих концепций. Но, во-первых, почему я хочу поговорить об Архитектуре внешнего интерфейса? Ну, для меня это очень личная тема. Почему? Потому что ежедневно мне приходится изо всех сил бороться, чтобы убедить не только руководство, но и команды разработчиков в том, что Архитектура внешнего интерфейса так же важна, как и Архитектура внутреннего интерфейса.
Зачем нам нужна Frontend-архитектура?
Функциональные и нефункциональные требования должны применяться не только к бэкенду, но и к внешнему интерфейсу. Таким образом, с помощью Внешней архитектуры мы можем выполнить бизнес-требования. Более того, мы можем лучше понимать сложность проектов, что приводит к снижению рисков, времени и затрат на любой проект. Однако, на мой взгляд, наиболее ценной причиной для Frontend Architecture является обслуживаемость и масштабируемость любого проекта.
Итак, как же выглядит архитектура внешнего интерфейса?
По моему опыту, в большинстве случаев используется многоуровневая архитектура. Однако я должен признать, что я также сталкивался с некоторыми проектами, в которых применялась гексагональная архитектура.
На следующем рисунке показан простой проект TripAgency.
Какие слои используются?
- API: DTO и сервисы, созданные генератором Open-API.
- Служба: включает сопоставители (DTO в модель внешнего интерфейса и наоборот) и службы, которые взаимодействуют через конечные точки REST с API.
- Хранилище: глобальное хранилище, содержащее все данные, полученные из слоя Сервис.
- Бронирование: Домен, включая Модели и Компоненты. Smart-Components взаимодействуют непосредственно с хранилищем, а немые компоненты — это всего лишь компоненты, которые можно применять более чем в одном контексте, поэтому они намного проще.
Так что же может пойти не так с такой архитектурой?
Что ж, если правила не определены, разработчики могут напрямую использовать DTO в своих компонентах или взаимодействовать с уровнем службы без хранилища. Или, что еще хуже, глупые компоненты взаимодействуют с сервисным уровнем.
Что мы должны сделать, чтобы предотвратить эти ошибки?
Просто определите некоторые правила, которые предотвращают это. Одним из наиболее распространенных подходов будет внедрение Bit или Nx в ваш проект. Что такое Бит? Что такое Nx?
Bit и Nx — это мощные системы сборки с открытым исходным кодом, которые предоставляют инструменты и методы для повышения производительности разработчиков, оптимизации производительности CI и поддержания качества кода [2][3]
Таким образом, с Bit или Nx можно применять правила зависимости. Поэтому разработчики получат ошибку, если будет использован неправильный слой.
Это правильный подход, но как мы можем быть уверены, что сам Домен, в приведенном выше примере Домен Booking, остается пригодным для обслуживания?
Мы можем применить некоторые концепции DDD (Domain Driven Design) к нашему домену бронирования. Поэтому мы разделяем домен бронирования на несколько поддоменов. Каждый поддомен имеет собственный ограниченный контекст и универсальный язык. Это может выглядеть так, как показано на рисунке ниже.
Каждый поддомен использует многоуровневую архитектуру, а для взаимодействия между этими поддоменами используются API. Feature включает Smart-Components и Services, UI Dumb-Components, Domain Models и Util все служебные функции, которые используются в этом ограниченном контексте.
Теперь у нас есть некая Чистая архитектура, не так ли? Мы близки, но мы еще не там. Недостаточно иметь архитектуру, базовые компоненты и бизнес-логика также должны использовать принципы Чистый код. Итак, давайте увеличим масштаб слоев Feature и UI.
Какие принципы следует применять к компонентам?
Прежде всего принцип SOLID. У каждого компонента должна быть только одна обязанность (принцип единой ответственности). Используйте композицию вместо наследования (принцип открытого-закрытого). Не заставляйте компоненты реализовывать неподходящие интерфейсы, т. е. не все методы имеют смысл (Разделение интерфейсов). И помните, что компоненты не должны напрямую зависеть от низкоуровневых сервисов (Инверсия зависимостей).
Во-вторых, применяя бизнес-логику к Компоненту, Сервису или Утилите, нельзя забывать о принципе KISS. Старайтесь, чтобы код был как можно короче и проще. Почему мы должны это делать? Более простой код легче поддерживать.
В-третьих, старайтесь не повторяться (принцип СУХОЙ). Переместите общую логику в Утилиты или Сервисы.
💡 Примечание. Эти принципы можно легко реализовать с помощью Bit. В Bit Workspace вы можете независимо создавать, тестировать, версии и документировать повторно используемые компоненты (функции, элементы пользовательского интерфейса или модели данных), которые затем можно публиковать на платформе совместного использования компонентов Bit, откуда вы (или другие) можете легко импортировать их в несколько проектов.
Узнать больше:
Звучит правдоподобно. Однако откуда знать, чего следует избегать? Короче говоря, что такое анти-шаблоны?
Антишаблоны
Со временем я столкнулся с некоторыми распространенными ошибками. Какие самые распространенные?
- Импорт ненужных библиотек, которые увеличивают размер пакета
- Использование вложенных подписок
- Добавление бизнес-логики в шаблоны
- Непроверенная бизнес-логика
Итак, это антипаттерны. Но как можно быть уверенным в том, что код остается ремонтопригодным? Как известно, бизнес-логика со временем растет. Короче говоря, я довольно часто слышал следующее утверждение.
Код исторически сложился. Сначала это был Чистый код, но теперь у нас есть то, что не так просто поддерживать, как раньше.
Да, это очень распространенная проблема. Тем не менее, следующие простые правила могут помочь сохранить ремонтопригодность.
- Определение eslint-правил
- Использование stylelint
- ТестированиеБизнес-логики
- Создание небольших повторно используемых компонентов
- Использование функций ES6 и Typescript
Подводя итоги
Я представил пример Чистой архитектуры и дал обзор некоторых принципов, которые можно применить. Более того, я взял DDD и поместил его в Архитектуру внешнего интерфейса. И наконец, что не менее важно, я представил некоторые правила, касающиеся создания компонентов и добавления бизнес-логики, чтобы код, надеюсь, оставался пригодным для сопровождения.
Тем не менее, команды разработчиков должны придерживаться высоких стандартов, когда речь идет о Code-Reviews и добавлении новых функций, иначе чистой архитектуры может оказаться недостаточно для дальнейшего обслуживания.
Надеюсь, это поможет вам создавать более чистые архитектуры внешнего интерфейса.
Ссылки
[1] https://medium.com/bitsrc/a-closer-look-on-signals-and-whats-still-missing-ba816b963a78
[2] https://bit.dev/docs/quick-start/hello-world/
[3] https://nx.dev/getting-started/intro
Создайте чистый интерфейс с повторно используемыми компонентами, как Lego
Bit – это цепочка инструментов с открытым исходным кодом для разработки компонуемого программного обеспечения.
С помощью Bit вы можете разрабатывать любую часть программного обеспечения — современное веб-приложение, компонент пользовательского интерфейса, серверную службу или сценарий CLI — как независимую, повторно используемую и компонуемую единицу программного обеспечения. Совместно используйте любой компонент в своих приложениях, чтобы упростить совместную работу и ускорить сборку.
Присоединяйтесь к более чем 100 000 разработчиков, которые вместе создают компонуемое программное обеспечение.
Начните с этих руководств:
