Архитектура: уровень ответственности и связь с модульностью

Question

В настоящее время я пытаюсь разработать архитектуру для моего нового проекта веб-приложения с такой концепцией:

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

Вот то, о чем я думал для архитектурных слоев для поддержки такого рода приложений:

1. Уровень пользовательского интерфейса

   • JSF 2.0 + виджеты Primefaces
   • Запрашиваемый объект ManagedBean + Flash для передачи данных между страницами
   • ManagedBean будет работать с состояниями пользовательского интерфейса, проверками пользовательского интерфейса, но не с операциями бизнес-логики
   • ManagedBean также имеет доступ к сервисному уровню, внедренному Spring
   • ManagedBean может иметь простые поля (например, строку, целое число и т. Д.), Или модели просмотра (для инкапсуляции некоторых связанных полей), или даже модели Entity, которые вначале должны быть временными объектами и однажды становиться отсоединенными получить и сохранить и выйти из сделки.
   • Эти комбинации полей можно использовать в зависимости от ситуации, и проверки, например, такие как @Required, будут помещены в метод установки ManageBean. Модель Entity может содержать @NotNull или @Size в полях.
   • Сущности в моем мышлении - это только JPA POJO с аннотациями JPA, определяющими отношения между сущностями без какого-либо поведения, за исключением тех проверок, которые определены также аннотациями.

2. Уровень обслуживания

   • Этот слой будет обрабатывать проверки и операции бизнес-логики
   • Модульность: Может также вызывать другой уровень обслуживания для других модулей, где другие модули могут отсутствовать, если они отключены через конфигурацию. Возможно, этого можно достичь с помощью другого уровня для связи между модулями, или я мог бы использовать Spring для внедрения пустых реализаций для отключенных модулей?
   • Ввод: он может принимать модели сущностей, или простые переменные, или просматривать модели
   • Вывод: возвращаемое значение может отличаться от void, Entity, списка сущностей (будет отображаться позже в таблице данных в JSF) и может представлять собой простые переменные, такие как логические, строковые, целые и т. Д.
   • В будущем этот слой также будет предоставлять веб-сервисы для мобильных устройств или другой язык, поддерживающий веб-сервис (я все еще не знаю как, но я думаю, что это возможно, даже если метод принимает объекты или объекты в качестве параметры)
   • Каждый объект службы будет иметь экземпляр DAO, внедренный Spring, и будет вызывать DAO для операций с данными, таких как операции CRUD, запросы и т. Д.

3. Уровень DAO

   • Будет иметь операции с данными, такие как операции CRUD, запросы (jpql, именованный запрос, запрос критерия, собственный запрос sql, хранимые вызовы proecure) и т. Д.
   • Ввод: он может принимать модели сущностей, или простые переменные, или просматривать модели
   • Вывод: возвращаемое значение может отличаться от void, Entity, списка сущностей (которое будет отображаться позже в таблице данных в JSF) и может быть простыми переменными, такими как логическое значение, строка, целое число и т. Д.
   • Наличие одного DAO для каждого объекта является нормой, но при работе с несколькими таблицами в одной операции с данными мне придется вводить новые DAO.
   • Будет добавлен EntityManager к весне

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

• Doman Driven Design (DDD), где у сущностей может быть постоянная логика? Я думаю, что это также активный шаблон записи? Spring roo, похоже, тоже порождает эту модель. Кажется, это противоположность Анемичной Модели Домена .
• объект передачи данных (DTO) , инкапсулирующий данные связи между уровнями, позволяющий избежать проблем с отложенной инициализацией в выгруженных отложенных иерархиях fetchtype при использовании JPA? Открытая сессия в представлении , похоже, имеет свои плюсы и минусы, а также в решении ленивого исключения.
• А некоторые скажут, что вам больше не нужен DAO, как описано в документации spring roo

И со всеми этими вопросами, пожалуйста, поделитесь своим мнением о моем текущем дизайне, когда дело доходит до:

• Скорость разработки, так как я думаю о том, чтобы иметь меньше шаблонов, потому что я могу использовать сущности, преобразовывая их в DTO и обратно
• Простота обслуживания, и я думаю о четком разделении между состоянием / логикой пользовательского интерфейса, логикой бизнес-процессов и уровнем операций с данными.
• Поддержка модульности, возможно, использование maven с каждым модулем в качестве одного артефакта, зависящего друг от друга при необходимости? <- здесь все очень туманно для меня </li>
• Веб-сервис в будущем. Я никогда раньше не пробовал веб-сервисы, но могу предположить, что публичные методы на сервисных уровнях можно экспортировать как веб-сервисы, чтобы их можно было вызывать с мобильных устройств или с любых других платформ, поддерживающих вызов веб-сервиса?

Не могли бы вы поделиться своим опытом в этом вопросе?

Answer 1

Найдите OR Mapper, который вам нравится, и не уделяйте больше внимания слою данных. Это в основном решаемая проблема, и большую часть внимания, которое вы уделите этому, будет заново изобретать колесо. Очень люди пишут приложения, чьи потребности в CRUD настолько уникальны, что в настоящее время они избегают использования ORM.

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

Итак, сконцентрируйтесь на сервисном уровне, где действительно выражена уникальность вашего приложения. Но мы не можем действительно проверить или критиковать ваш уровень обслуживания, потому что мы ничего не знаем о проблеме, которую вы пытаетесь решить. Все, что вы перечислили, безусловно, является хорошим подходом для определенных задач, определенных наборов компромиссов и т. Д. Не зная больше о том, что имеет значение (производительность / время разработки / конфигурируемость / надежность / ясность), никто не может сказать вам, что правильный набор вариантов выбора.

На вашем элементе «output» - другие устройства могут поддерживать связь с вашим приложением, если все сериализуется до общего формата, обычно XML. Затем вы просто отправляете его по проводу и повторно увлажняете на другом конце.

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