Есть ли смысл разделять части веб приложения на различные мавен-модули, если разрабатываешь целостное решение для конкретной проблемы? Вообще говоря практика полезная с определенной точки зрения. С другой точки зрения смысла нет. Рассмотрим обе.
Итак, точка зрения первая - модульная. С точки зрения модульности приложение должно состоять из самодостаточных модулей, так сказать собираться из кубиков. Такой подход позволяет добиться повторного использования конкретной части приложения. Например, сущностей модели или логики предметной области. Также этот подход весьма удобен в плане масштабируемости приложения и его изменяемости. Предположим, что есть у вас система резервирования номеров в отеле. Построена она по модульному принципу с помощью Spring MVC. Тут возникла необходимость реализовать RESTfull API для бронирования номеров. Ну допустим, мобильное приложение разрабатывается. В том случае, если система бронирования монолитна - придется дорабатывать весь проект, так как необходимо будет убедится в том, что внесенные изменения никоим образом не затрагивают основной функционал и уж тем более, не нарушают его. Вторая проблема - переразворачивать на сервере придется опять же весь проект, что может привести к известным проблемам с работой все того же основного функционала, начиная с перебоев в режиме работы (что не критично - ночные сборки никто не отменял), заканчивая явными багами в том случае, если внесенные правки все же задели основной функционал.
С другой стороны если структура приложения у вас модульная - то REST api - это просто отдельное приложение, которое крутится себе рядом с основным приложением, использует его внутренний слой API и никак не влияя на основную логику. Проект меньше, разрабатывать проще, тестировать быстрее.
Еще одна прелесть - если вам вдруг понадобятся сущности из модели этого приложения, то достаточно будет зависеть только от модуля модели данных, если сервисы, то только сервисы - не надо тянуть в зависимости все толстенное приложение.
С другой стороны, грамотное разделение на модули довольно трудоемкий процесс и простое приложение превращает в громоздкое (с точки зрения восприятия). Как же быть? А быть надо в зависимости от обстоятельств. Если вы пишите прототипчик или просто маленькую вещь, цель которой - улучшить ваши навыки - в топку модульность! Не нужна она тут. Только потеря времени. Однако, если речь идет о чем-то более основательном, хоть это сайтик для себя любимого, а тем более если коммерческий проект - грамотное проектирование должно быть на первом месте.
Итак, точка зрения первая - модульная. С точки зрения модульности приложение должно состоять из самодостаточных модулей, так сказать собираться из кубиков. Такой подход позволяет добиться повторного использования конкретной части приложения. Например, сущностей модели или логики предметной области. Также этот подход весьма удобен в плане масштабируемости приложения и его изменяемости. Предположим, что есть у вас система резервирования номеров в отеле. Построена она по модульному принципу с помощью Spring MVC. Тут возникла необходимость реализовать RESTfull API для бронирования номеров. Ну допустим, мобильное приложение разрабатывается. В том случае, если система бронирования монолитна - придется дорабатывать весь проект, так как необходимо будет убедится в том, что внесенные изменения никоим образом не затрагивают основной функционал и уж тем более, не нарушают его. Вторая проблема - переразворачивать на сервере придется опять же весь проект, что может привести к известным проблемам с работой все того же основного функционала, начиная с перебоев в режиме работы (что не критично - ночные сборки никто не отменял), заканчивая явными багами в том случае, если внесенные правки все же задели основной функционал.
С другой стороны если структура приложения у вас модульная - то REST api - это просто отдельное приложение, которое крутится себе рядом с основным приложением, использует его внутренний слой API и никак не влияя на основную логику. Проект меньше, разрабатывать проще, тестировать быстрее.
Еще одна прелесть - если вам вдруг понадобятся сущности из модели этого приложения, то достаточно будет зависеть только от модуля модели данных, если сервисы, то только сервисы - не надо тянуть в зависимости все толстенное приложение.
С другой стороны, грамотное разделение на модули довольно трудоемкий процесс и простое приложение превращает в громоздкое (с точки зрения восприятия). Как же быть? А быть надо в зависимости от обстоятельств. Если вы пишите прототипчик или просто маленькую вещь, цель которой - улучшить ваши навыки - в топку модульность! Не нужна она тут. Только потеря времени. Однако, если речь идет о чем-то более основательном, хоть это сайтик для себя любимого, а тем более если коммерческий проект - грамотное проектирование должно быть на первом месте.
Комментарии
Отправить комментарий