architecture rules
google code landing page

Assert Your Architecture! with this open source java library. Architecture Rules leverages an xml configuration file and optional programmatic configuration to assert your code's architecture via unit tests or ant tasks. This test is able to assert that specific packages do not depend on others and is able to check for and report on cyclic dependencies among your project's packages and classes. This project wraps a industry accepted JDepend to simplify the process of maintaining a solid software architecture.

  1. architecture-rules-2.0.2.jar
  2. architecture-rules-2.0.2-sources.jar
  3. architecture-rules-2.0.2-test-sources.jar

Introduction

JDepend traverses Java class file directories and generates design quality metrics for each Java package. JDepend allows you to automatically measure the quality of a design in terms of its extensibility, reusability, and maintainability to manage package dependencies effectively.

However, experiences using JDepend have been in maintaining difficult configuration and stumbling while trying to get a quick overview of the established rules.

Enter: Architecture-Rules

Check out how to get started and a sample configuration now, or continue reading to learn the benefits of Asserting your Architecture.

Benefits

  • Assert your architecture through unit tests
  • Fail a build when architecture rules are broken
  • Allow any IDE with unit testing capabilities to enforce an architecture
  • Allow continuous integration servers to enforce an architecture
  • Easy to read and maintain architecture rules and configuration
  • Allows for multiple architecture configuration. One for each module.

Why assert your architecture?

JDepend explains why you should design a good architecture and why you should monitor it.

Here are some applicable experts:

Identify Package Dependency Cycles

Packages participating in a package dependency cycle are in a deadly embrace with respect to reusability and their release cycle. Package dependency cycles can be easily identified by reviewing the textual reports of dependency cycles. Once these dependency cycles have been identified with JDepend, they can be broken by employing various object-oriented techniques.

Package Release Modules

Packages that are cohesive and independent can be released as autonomous modules with their own release schedules and version numbers. Single packages, or groups of related packages collaborating in a framework, that are candidates for independent release can be harvested by evaluating their design quality metrics using JDepend.

Isolate Third-Party Package Dependencies

Third-party package dependencies can be easily identified and isolated by examining the afferent couplings to those packages. Once the dependency on these third-party packages has been measured with JDepend, the dependency can be managed by effectively designing abstract and stable packages that encapsulate the third-party package implementation details.

Invert Dependencies

The goal of using JDepend is to ultimately invert package dependencies such that low-abstraction packages depend upon high-abstraction packages. This inversion of dependencies allows the high-abstraction packages to be reused independently while being extensible to an open set of implementations. In general, dependencies upon stable packages are desirable, while dependencies upon instable packages are undesirable. JDepend allows dependencies to be interactively examined and refactored as an integral part of software design and development.