Цель этой статьи — объяснить причины, побудившие меня предложить «Чистую архитектуру» в качестве архитектуры для разработки проектов в нашей компании. Узнав об этом, проекты Codegenio разрабатываются в соответствии с этой архитектурой, и мы решаем проблемы сопряжения, обслуживания и производительности в целом. Прежде чем ответить, почему мы используем эту архитектуру, я представлю несколько основных концепций для лучшего понимания.

Что такое архитектура программного обеспечения?

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

Что такое чистая архитектура?

Чистая архитектура — это сборник принципов и шаблонов разработки, направленных на облегчение процесса создания программного обеспечения, а также его обслуживания. Это относится к организации проекта, позволяющей легко понять и изменить его по мере роста проекта или необходимости замены одной из используемых технологий либо потому, что она устарела, либо по любой другой стратегической причине.

Сходства между архитектурами

Применение Чистой Архитектуры было не так уж сложно усвоить команде. Доменно-ориентированные архитектуры, такие как Многоуровневая архитектура, предложенная Эриком Эвансом, Чистая архитектура дяди Боба, Луковая архитектура Джеффри Палермо, имеют с ней общие черты.

Каждая из этих архитектур создает системы, обладающие следующими характеристиками:

  • Независимо от фреймворков. Архитектура не зависит от наличия какой-либо библиотеки многофункционального программного обеспечения. Это позволяет вам использовать такие фреймворки в качестве инструментов, а не заставлять вас втискивать вашу систему в их ограниченные ограничения.
  • Тестируется. Бизнес-правила можно протестировать без пользовательского интерфейса, базы данных, веб-сервера или любого другого внешнего элемента.
  • Независимо от пользовательского интерфейса. Пользовательский интерфейс можно легко изменить, не меняя остальную часть системы. Например, веб-интерфейс можно заменить консольным интерфейсом без изменения бизнес-правил.
  • Независимо от базы данных. Вы можете заменить Oracle или SQL Server на Mongo, BigTable, CouchDB или что-то еще. Ваши бизнес-правила не привязаны к базе данных.
  • Независим от каких-либо внешних агентств. На самом деле ваши бизнес-правила вообще ничего не знают об интерфейсах с внешним миром.

Следующая диаграмма представляет собой попытку объединить все эти архитектуры в единую действенную идею.

Преимущества

  • Создание несвязанных приложений, которые легче тестировать.
  • Больше гибкости для добавления или удаления программных функций.
  • Компонентный дизайн с четко определенными обязанностями.
  • Откладывание важных решений до последнего необходимого момента.

Основное использование

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

Вывод

Соблюдать эти простые правила несложно, и это избавит вас от многих головных болей в будущем. Разделив программное обеспечение на слои и соблюдая правило зависимостей, вы создадите систему, которую можно тестировать по сути, со всеми вытекающими из этого преимуществами. Когда какая-либо из внешних частей системы устаревает, например база данных или веб-фреймворк, вы можете заменить эти устаревшие элементы с минимальными усилиями.

Эти преимущества получены не случайно, необходимо целенаправленное планирование, из-за них наша компания использует Чистую Архитектуру.

Эта статья была изначально опубликована Маркосом Гонсалесом в блоге Codegenio.