Недавно я присоединился к новому проекту, и, как всегда, одной из моих первых задач было ознакомиться с существующей кодовой базой.
В этом JEE-проекте одной из самых важных вещей для меня было узнать, как классы распределялись по разным пакетам. Обладание этими знаниями означало бы, что, даже если бы я не знал, как что-то работает, я мог бы легко знать, где искать, а затем узнать, как работает код.
В этом сообщении в блоге я хочу показать два наиболее известных шаблона архитектурного проектирования о том, как можно организовать код.
Или горизонтальный подход.
Представьте себе торт с несколькими слоями.
Каждый слой представляет собой пакет.
Каждый пакет содержит именно то, за что отвечает этот слой.
Итак, представьте, что вы организуете свой код в 4 слоя, скажем:
- пользовательский интерфейс
- Бизнес-логика
- ДАО
- Модель
(это, конечно, не самый оптимальный способ организации ваших слоев и используется только для удобства представления)
У нас было бы 4 слоя или 4 упаковки.
Пользовательский интерфейс отвечает за обработку всего, что связано с пользовательским интерфейсом. Таким образом, здесь будет создан каждый класс пользовательского интерфейса, связанный с любой функцией.
То же самое относится и к остальным трем слоям. Бизнес-логика отвечает за все, что связано с бизнес-правилами, DAO обрабатывает доступ к базе данных, Модель содержит, например, Объектно-реляционную модель для базовой базы данных.
Если бы мы хотели создать приложение, которое может создавать некоторые задачи, а затем перечислять их, мы могли бы разделить их соответственно на 4 пакета.
- пользовательский интерфейс
- пользовательский интерфейс
- пользовательский интерфейс
- Бизнес-логика
- Бизнес-логика
- Бизнес-логика
- ДАО
- ДАО
- ДАО
- Модель
- Модель
- Модель
Преимущества
Добавлять новые классы в такой среде действительно легко. Например, если кто-то захочет создать новый класс модели, он может просто сделать это, добавив его в пакет модели, не задумываясь дважды.
Это также означает, что новым членам команды будет легко научиться тому, как организовать код.
Недостатки
Большим недостатком этого подхода является то, что действительно сложно оценить сложность функции, потому что вы не знаете, где находится или может использоваться функция и какие зависимости она может иметь от других функций.
Кроме того, подумайте об инкапсуляции. Все должно быть общедоступным .
Бизнес-правило, вероятно, должно каким-то образом получить доступ к DAO. Но почему пользовательский интерфейс также может получить доступ к DAO? Потому что либо только другие ДАО могут получить доступ к моему ДАО, либо каждый может.
Конечно, этот аргумент применим только в том случае, если вы все еще используете Java8, как и я. В противном случае вы могли бы использовать Jigsaw (модульная система Java 9) для создания модулей.
Или вертикальный подход.
Представьте себе торт с несколькими ломтиками.
Каждый кусочек представляет собой упаковку.
Каждый пакет содержит именно то, за что отвечает эта функция.
Итак, представьте себе наш предыдущий пример приложения, если бы вы организовали свой код в структуру пакета, подобную функциям, это могло бы выглядеть так.
- Список задач
- Список задач
- Список задач
- Список задач
- Список задач
- Задача Создать
- Задача Создать
- Задача Создать
- Задача Создать
- Задача Создать
Преимущества
В отличие от архитектуры слоев, вы действительно можете использовать инкапсуляцию в такой структуре, так как каждая функция инкапсулирована в свой собственный пакет . Только API, которые действительно должны быть общедоступными, могут быть общедоступными.
В современных архитектурах очень часто создаются микросервисы . Благодаря уже существующей структуре очень легко извлечь существующие функции в архитектуру микросервиса.
Расширяемость (если это слово, то оно здесь подходит): Если функция нуждается в расширении за счет какой-либо функциональности, вы сразу знаете, куда вам нужно идти и в каком контексте вы будете работать. Вы также можете быть более уверены в том, что при внесении изменений в некоторые функции вы, вероятно, не нарушите работу всего приложения, а только той функции, над которой работаете.
Недостатки
Большие приложения с большим количеством функций будут быстро расти не только в количестве классов, но и в количестве пакетов . С одной стороны, может быть трудно отслеживать все функции, но, с другой стороны, также может быть проще идентифицировать определенные функции, если пакеты имеют более значимые имена, чем просто их слой.
Вы действительно должны знать, что вы делаете . Является ли это недостатком или нет, вы должны решить сами. Но также подумайте о новых людях, присоединяющихся к команде. Вместо того, чтобы сразу найти подходящее место для каждого класса, они на самом деле должны знать, над чем они сейчас работают, чтобы точно выбрать правильный пакет для своего нового класса.
Итак, что вы должны выбрать для своего проекта? Как всегда, все зависит от обстоятельств.
В целом, основываясь на количестве преимуществ, которые я перечислил для одного из шаблонов, я предпочитаю архитектуру функций . Это дает вам больше стабильности в том, как вы работаете. Если вы меняете класс, вам на самом деле не нужно проводить регрессионный тест для всего приложения (по крайней мере, теоретически). Но архитектура слоя также имеет свои сильные стороны. Я полагаю, что в небольших проектах такая архитектура действительно была бы полезна, потому что вы можете получить более быстрый обзор всех ваших классов.
В заключение я хотел бы сказать, что ни одно из этих решений не является правильным ответом на все ваши проблемы. Каждая команда должна выяснить, какая архитектура соответствует их требованиям или их проекту. Во многих случаях я видел комбинацию того и другого. Вы можете организовать свои классы в пакеты функций (Архитектура функций), и в этих пакетах вы разделяете свои классы на слои (Архитектура слоев). Только команда может решить, что для нее хорошо.
Оригинал: “https://dev.to/smotastic/layer-vs-feature-architecture-3cko”