Я хочу быть уверенным, что мой проект не содержит ненужных зависимостей между пакетами. Например, я хочу быть уверенным, что проект имеет многоуровневую структуру. То есть модель ниже всего, бизнес-логика зависит от модели, взгляд зависит от бизнес-логики и модели. Каждый из слоев находится в своем собственном пакете.
Не могли бы вы порекомендовать любые, предпочтительно, инструменты с открытым исходным кодом, которые позволяют мне указывать эти ограничения и проверять их как часть непрерывной интеграции?
P.S. Я знаю, что я могу отделить проект в отдельных модулях maven. К сожалению, мой случай в реальном мире более сложный, чем трехслойная система. Если бы я использовал модули maven, у меня было бы несколько десятков довольно маленьких модулей.
Structure101 позволяет визуально определять ваши слои как ячейки в Архитектура Диаграммы, которые сопоставляются с физическим кодом и проверяют соответствие. Эти диаграммы видны в IDE разработчиков и генерируют предупреждения о времени редактирования, если правила разбиения слоев нарушены. Также возможно разбивать/сообщать сборку во время CI. SonarJ и Lattix - это другие инструменты для визуального контроль зависимостей.
Хотя я не уверен, возможно ли принудительное выполнение сбоя сборки при нарушении зависимости уровня, есть хотя бы инструмент, который может проверять и визуализировать эти слои: Sonar. Вы можете интегрировать его с вашими сборками maven и jenkins, а также с eclipse (и, возможно, с другими IDE).
Sonar имеет вид матрицы зависимостей, который визуализирует взаимозависимости пакетов.
EDIT: возможно, можно настроить сонар, чтобы заставить сборку сбой срабатывать с помощью нарушения: build breaker
Это очень важный вопрос, поскольку многие проекты обеспечивают зависимость между модулями Maven, что представляет собой огромную трату производительности и гибкости.
Проведя много времени на эту тему, я мог бы порекомендовать два инструмента:
Оба инструмента не развиваются в последние годы, но работают хорошо. Macker имеет синтаксис на основе XML, но Classycle имеет опрятный DSL. Classycle - это более специализированный инструмент высокого уровня и имеет понятие слоев. Эти инструменты позволяют обеспечить жесткие барьеры между пакетами и определенными типами классов. Эти инструменты должны быть сконфигурированы в процессе сборки для сбоя при любом ограничении.
Проверьте пример иерархии (http://innig.net/macker/example/layering/src/macker.xml) и здесь (<а3 > ).
По-прежнему существует ниша для хорошего инструмента с открытым исходным кодом, который будет подключаться к компилятору и даст вам ошибки, когда вы находитесь в среде IDE, а не в инструменте построения. Structure101 гораздо более функционально богатый, но также тяжелый и полагается на плагин Eclipse.
Обновление
Это также JQAssistant, что очень мощно, но может пройти довольно много времени, чтобы узнать и настроить.
JDepend может анализировать вашу базу кода и предоставлять вам показатели, которые вы ищете. Три основных показателя, которые вы ищете, - это Afferent Couplings, Efferent Couplings и Циклы зависимостей пакетов.
Architexa - еще один инструмент, который может помочь здесь.
Вы можете использовать Checkstyle для реализации "индивидуальных проверок". Посмотрите, чтобы узнать больше: http://saturnnetwork.wordpress.com/2012/11/26/ultimate-architecture-enforcement-prevent-code-violations-at-code-commit-time/
Я не пробовал это сам, но я думаю, что это непросто реализовать, и это бесплатно.
Существует несколько инструментов, которые могут помочь вам в применении вашей многоуровневой архитектуры и ограничений зависимости в целом. Эти инструменты зависят от языка. Если вы используете Java, я могу предложить создать ваши пользовательские проверки с помощью checkstyle.
Я написал текст, на который Антон упомянул (Ultimate Architecture Enforcement). Это основано на нашем собственном успешном опыте. Пользовательские проверки могут быть интегрированы в IDE (например, Eclipse), могут быть интегрированы в инструмент непрерывной интеграции (например, Jenkins), а в качестве последнего средства для предотвращения нарушений могут быть выполнены автоматически в качестве предварительной проверки на Subversion. Собственные проверки сами записываются на Java с помощью API checkstyle.