Даниэль Дойч

В проекте с открытым кодом, в который я начал участвовать, мне принесли концепцию «чистой архитектуры».

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

Содержание

Визуальные представления

Я думаю, что всегда хорошо начинать с визуализации.

Вот самые распространенные изображения этой концепции.

Концепция — представлена ​​в пунктах

Расширено с Источник и кредит: Маттиа Баттистон, согласно CC BY 4.0

Ценность, которую она может предоставить

• Эффективная стратегия тестирования, соответствующая пирамиде тестирования
• Фреймворки изолированы в отдельных модулях. Когда (не если) мы передумаем, нам нужно измениться только в одном месте. Программа имеет варианты использования, а не привязана к системе CRUD
• Кричащая архитектура, ака она кричит о своем целевом использовании. Когда вы смотрите на структуру пакета, вы получаете ощущение, что делает программа, а не видите технические детали
• Вся бизнес-логика находится в варианте использования, поэтому ее легко найти и нигде больше не дублировать
• Сложно сделать неправильную вещь, потому что модули обеспечивают компиляционные зависимости. Если вы попытаетесь использовать то, что вам не предназначено, программа не компилируется
• Он всегда готов к развертыванию, оставляя подключение объекта напоследок. Или с помощью флажков функций, чтобы получить все преимущества непрерывной интеграции
• Несколько работ над историями, чтобы разные пары могли легко работать над одной историей одновременно, чтобы завершить ее быстрее
• Хороший монолит с четкими вариантами использования, которые вы можете разбить на микросервисы позже, когда узнаете о них больше

Сущности

• Представлять свой объект домена
• Применять только логику, которая в целом применима ко всему объекту (например, проверка формата имени хоста)
• Простые объекты: без рамок, без аннотаций

Случаи использования

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

Интерфейсы / Адаптеры

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

Внешние интерфейсы

• Используйте любой подходящий фреймворк (в любом случае они будут изолированы здесь)

Пример кода

Смотрите структуру GitHub.

Прежде всего, важно понимать, что чистая архитектура – ​​это связь организационных принципов. Поэтому все открыто для личных конфигураций, пока главные идеи остаются постоянными. Связанный репозиторий является форком оригинального проекта, принесшего мне эту идею архитектурного дизайна. Не стесняйтесь также ознакомиться с оригинальным проектом, поскольку он отражает дальнейшие усовершенствования.

Папка webminer структурирована на основные слои:

1. юридических лиц
2. случаи использования
3. interfaces_adapters
4. внешние_интерфейсы

Он должен отображать самый основной подход к шаблону проектирования.

• Начиная с entitiesвы можете увидеть, что основной моделью этого проекта является arxiv_document
• Следующая папка, use_cases показывает наш вариант использования, а именно запрос на страницу arxiv
• После этого проходим через interface_adapters папка, которая предоставляет адаптеры для запросов на процесс в программе REST или сериализации
• Последний и последний слой external_interfaces. Именно здесь мы используем сервер flask для реализации функциональности REST

Все эти слои зависят от основных слоев, но не наоборот.

Одно важное замечание: это не на 100% правильно реализовано в репозитории.

Почему? Потому что варианты использования действительно разные. На самом деле, основным вариантом использования является предоставление структурированных данных. Другим вариантом использования является получение данных со страницы arxiv.

Вы заметили это заблуждение в архитектуре? Если да, то поздравляю! Вы не только заинтересовали эту статью, но и, вероятно, хорошо понимаете принципы, чтобы построить собственное дело и применить концепции в реальности!

Вы согласны? Если нет, то почему? Спасибо, что прочли мою статью! Не стесняйтесь оставлять любой отзыв!

Ресурсы

Вот некоторые статьи, которые я нашел полезными для понимания концепции чистой архитектуры:

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

Подключиться на: