Подтвердить что ты не робот

Архитектурные ограничения в Java

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

Не могли бы вы порекомендовать любые, предпочтительно, инструменты с открытым исходным кодом, которые позволяют мне указывать эти ограничения и проверять их как часть непрерывной интеграции?

P.S. Я знаю, что я могу отделить проект в отдельных модулях maven. К сожалению, мой случай в реальном мире более сложный, чем трехслойная система. Если бы я использовал модули maven, у меня было бы несколько десятков довольно маленьких модулей.

4b9b3361

ОТВЕТЫ

Ответ 1

Structure101 позволяет визуально определять ваши слои как ячейки в Архитектура Диаграммы, которые сопоставляются с физическим кодом и проверяют соответствие. Эти диаграммы видны в IDE разработчиков и генерируют предупреждения о времени редактирования, если правила разбиения слоев нарушены. Также возможно разбивать/сообщать сборку во время CI. SonarJ и Lattix - это другие инструменты для визуального контроль зависимостей.

Ответ 2

Хотя я не уверен, возможно ли принудительное выполнение сбоя сборки при нарушении зависимости уровня, есть хотя бы инструмент, который может проверять и визуализировать эти слои: Sonar. Вы можете интегрировать его с вашими сборками maven и jenkins, а также с eclipse (и, возможно, с другими IDE).

Sonar имеет вид матрицы зависимостей, который визуализирует взаимозависимости пакетов.

EDIT: возможно, можно настроить сонар, чтобы заставить сборку сбой срабатывать с помощью нарушения: build breaker

Ответ 3

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

Проведя много времени на эту тему, я мог бы порекомендовать два инструмента:

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

Проверьте пример иерархии (http://innig.net/macker/example/layering/src/macker.xml) и здесь (<а3 > ).

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

Обновление

Это также JQAssistant, что очень мощно, но может пройти довольно много времени, чтобы узнать и настроить.

Ответ 4

JDepend может анализировать вашу базу кода и предоставлять вам показатели, которые вы ищете. Три основных показателя, которые вы ищете, - это Afferent Couplings, Efferent Couplings и Циклы зависимостей пакетов.

Architexa - еще один инструмент, который может помочь здесь.

Ответ 6

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

Я написал текст, на который Антон упомянул (Ultimate Architecture Enforcement). Это основано на нашем собственном успешном опыте. Пользовательские проверки могут быть интегрированы в IDE (например, Eclipse), могут быть интегрированы в инструмент непрерывной интеграции (например, Jenkins), а в качестве последнего средства для предотвращения нарушений могут быть выполнены автоматически в качестве предварительной проверки на Subversion. Собственные проверки сами записываются на Java с помощью API checkstyle.